Re: The ports-system and userland in general.

[Weapon of Mass Deduction <blacklist@xxxxxxxxxxx>]

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)