The ports-system and userland in general.

[Magnus Eriksson]

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.  :-)

  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.


  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.




> >   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.



> >   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.



> >   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..


> 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.


Magnus