Re: The ports-system and userland in general.

[Magnus Eriksson <magetoo@xxxxxxxxxxx>]

On Tue, 14 Dec 2004, Weapon of Mass Deduction wrote:

> I'm currently thinking out a good userland
> architecture, so I would like to know what
> qualities he or others is/are especially looking
> for then.

Seems I missed some of the discussion.  Anyway, here's my thoughts.
Mostly semi-random, but I've thought of some things before and this seems
like a good time to get them off my chest.  :-)

  My main experience is with pkgsrc, by the way.




  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.


  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.


  Separate out building from installing.  Kind of obvious that you'd want
to minimize downtime, but still..


  Make it work for novice users.  Ideally, you should be able to use all
the features without having to tweak things yourself.  If there are things
that can not be simplified enough (crossbuilding, batch runs, distcc?),
consider making a sharp distinction and marking the feature as for
advanced users.  (Try to avoid "No, it's really simple to do that with
pkgsrc, just install package xyz and change this .conf file to ..." --
people *will* get things wrong and break things on their systems)


  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?


  Dry runs.  If I can simulate a major upgrade successfully, I'll be much
more comfortable doing it for real.


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



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



  Please note this is just ideas and thoughts.  Goal X may very well be
incompatible with goal Y, I'm sure there are things I didn't think of,
etc..


Magnus