Re: The ports-system and userland in general.

[Weapon of Mass Deduction <blacklist@xxxxxxxxxxx>]

Magnus Eriksson wrote:
> On Thu, 16 Dec 2004, Weapon of Mass Deduction wrote:
>
> > Magnus Eriksson wrote:
> > >  Please think of a system that does not depend on magic Makefiles.  Make
> > > a specification that anyone can implement, be it with 'make install' like
> > > command-line tools, graphical package selection or whatever.  Just leave
> > > room for smart implementations you haven't thought of yet.
>
>
> > I am certainly thinking about that too. However, much software today
> > comes with those nasty makefiles, sadly...
> > Though we could of course replace their functionality. But that might
> > be a bit too ambitious in this stage. ;)
>
>
> > >  Separate out building packages from package management, if at all
> > > possible.  You should be able to walk the dependency tree (and configure
> > > packages) before anything gets written to disk.
>
>
> > I do not understand what you exactly mean by this. In which way you
> > would say the building process interferes package management or vice
> > versa, or in which way is it cluttered with the package management or
> > vice versa?
>
>   I'm not sure I understand what you wrote either.  :-)

Hehe. Well, I just strive to formulate exactly. But I should try to write
more clear also. ;)

>   But basically what I meant in those two paragraphs is that package
> management should be completely separate from package building.  I.e, the
> same basic system should work for both binary and source packages;
> fetching a binary package should be logically equivalent to fetching and
> compiling a source package; and handling dependencies, installing packages
> should be separate from the fetching / compiling step.  (Put another way,
> please, please, please, no recursive makes.)
>
>  I guess this is where someone will tell me why it can't be done.

Apparently that might be likely, but I think it is not.

My point of view in pseudo-code:
Complexity != impossibility
!Feasibility, ...  ---> impossibility

(Just to not spend too much words... :D)

However, my question to you was: why would this be a problem for pkgrsc 
and its likes? Some issues you describe are - indeed - applicable to 
pkgsrc etc., but how do you mean building is interfering with the
package management in the current situation? I mean I am not under
the impression that is true, though I might be wrong of course.

>   In the first paragraph, I don't mean that we should try to have our own
> replacement for Makefiles for building from source, that would be stupid.

Well, if you put it that simple, I couldn't agree with you more.

> > >  For binary packages: Always have a minimal build, as well a typical
> > > build ("Surely, *everyone* wants OpenGL support in their xmms...").
> > >
> > >  For "some compiling required" packages: Have minimal and typical
> > > configurations that can be selected, as well as letting the user
> > > customize.  And list options relevant for the package!  (with/out X11,
> > > Truetype ...)  I'm thinking maybe checkboxes?
>
>
> > Well, that could a be realized with pkgsrc and its likes. But, as I
> > already wrote in my posting before this one, it is merely a problem
> > of the software packages of today that they leave no clear separation of
> > compilation and configuration. Which makes it, as far as I can tell,
> > impossible to do a 'minimal build' on the usual, fully compiled binary
> > packages.
>
>
>   Well, it can sort of be accomplished with pkgsrc.  Before the configure
> step, you'll usually get an on-screen message saying "The following flags
> may affect the build of this package; USE_X11", or something similar,
> scrolling by.  I think the ports system is better in this regard, with the
> menu thingy that some packages gives you.

Yes, but please discern all aspects *strictly*. The configure step you 
write of, is a step *only* applicable to building-processes, not the 
installation of binary packages.

Also, I reminded of the fact that it is a problem of the software 
packages *themselves*. They shouldn't require users to compile-in 
configuration options. So, its not our task, in a way.

> > >  If possible, the package system should be portable.  If not possible,
> > > make it work on DF instead of sacrificing good features.  For "all other
> > > platforms" there's already pkgsrc..
>
>
> > Portability came into my mind today in fact. :)
> > But define portability... UNIX? Or more?
> > More might be possible, at least I already thought a bit about it
> > and see no unovercomable obstacles. But would it be useful?
> > The packages distributed by systems like pkgsrc are UNIX-only,
> > as far as I know. And those are the ones we would be primarily
> > interested in.
>
>
>   IMHO it would be too hard trying to extend the package system beyond
> UNIX-like platforms.  But then if it can be done, why not?  If you have a
> clean separation, the dependency handling should be similar across
> platforms, even if the building part isn't.

Okay. Then I think we are in accord about this. Just make a technically 
clean architecture, which should enable us to realize this, but not
set it as a goal (for now at least).

> > >  Dependencies.
> > >
> > >  There's two sides to this argument, but personally I'd like to see
> > > dependencies being specified only in terms of capability / major versions
> > > / API revisions.  The other, IMO, is forcing dependencies to be of the
> > > "best" version (for example security-wise).  In my opinion, depending on
> > > specific versions just ties packages tighter together and makes it harder
> > > to replace just a single one, and you'll have a bigger and bigger mess as
> > > the package collection grows.  On the other hand, this shifts more
> > > responsibility to the user having to keep track of which versions work
> > > well..
>
>
> > As a wrote more times: mostly the one thing doesn't exclude the other. :)
>
>
>   It should.  I'd prefer a strict adherence to one or the other, so that
> at least you'll know what to expect.  Preferably minimal dependencies, and
> then having security checks separate.  Maybe I'm misunderstanding you
> again..

Yes, you are, I suspect. :P

* You think I meant:
Facts:
- Approach 1 -> benefit 1, deficit 1.
- Approach 2 -> benefit 2, deficit 2.

Choose: Approach 1+2 -> benefit 1+2. But, manage in some way to not 
suffer from deficit 1+2.

* You would however like to see:
Facts:
- Approach 1 -> benefit 1, deficit 1.
- Approach 2 -> benefit 2, deficit 2.

Choose: Approach 1 OR 2 -> benefit 1 OR 2. Manage in some way to not 
suffer from deficit 1 OR 2, AND find a way to obtain the other benefit 
(1/2).

* What I *really* mean:
Facts:
- Approach 1 -> benefit 1, deficit 1.
- Approach 2 -> benefit 2, deficit 2.
- Approach 3 -> benefit 1+2, WHY: this solution is not of the same class 
as Approach 1/2.

Choose: Approach 3, IF: it has been fully worked out, and thus its 
theoretical existence is also found practical.

> > I had a software system in mind that lets users determine this
> > themselves. This way problems with dependencies can and will be reported
> > to the authors of the software in question, instead of the 'porters'.
> > Of course, reasonable predefines should be shipped when requested to...
>
>
>   Won't work.  Say I'm the author of "SnazzyMusic" (currently at version
> 1.2.3).  One day comes a report that SnazzyMusic (version 1.1.1) won't
> build on ObscureBSD because of a conflict with ClosedSSL.  What should I
> do?  Why should I care?  It works just fine on my Linux box, after all.

Misunderstanding again. :D

YOU shouldn't do anything! :)
The ObscureBSD users who experiences the problem you describe should, in 
my solution. What? He could fix it himself, but he probably reports his 
troubles to the software author(s), because the fault must be on their 
side (considering the perfectness of our software system B-)).

> Magnus

--
Greetings,
WMD (tfa . x @ inter . nl . net)