The ports-system and userland in general.

[Weapon of Mass Deduction]

Magnus Eriksson wrote:
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.
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?

  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)
I'm certain Matthew is a warm supporter of easy-to-use distcc building,
as he did start out this grid-computing friendly BSD-variant for a 
reason, of course.

I think it goes without saying that any new software system shall be 
made novice-friendly, *really* novice-friendly.

  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.

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

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

  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
--
Greetings,
WMD (tfa . x @ inter . nl . net)