[aps-devel] Fwd: GNU package management

[Robert Millan]

On Wed, Nov 27, 2002 at 02:14:42PM +0100, Wolfgang Jaehrling wrote:
> Lambda Marco and Robert!
> 
> This mail is a follow-up on the discussion I had with Marco yesterday.
> I promised to explain the strategy and design I came up with for the
> package manager, so here it is.
> 
> RMS' suggestion was that the file system that unites the package
> directories should also provide a node where you can lookup problems,
> like unresolved dependencies and conflicts, and should hide the
> packages which currently have such problems.  This will enable the
> user to manipulate the package system manually without messing up
> things, and I hope we can all agree that this is the Right Thing, even
> if we will have frontends which take care that everything is alright.
> 
> It is possible to implement this, but it will take long, since we need
> a working UnionFS (we are far away from that still, as far as I can
> tell) and then have to base the package management on it, so whoever
> works on it needs to know a lot about file systems in the Hurd in
> general and about UnionFS in particular, so few people will be able to
> help.
> 
> I think I came up with a different strategy, which will cause us to
> *end up* with the Right Thing, but should be easier to accomplish.
> 
> We will write a package manager frontend that does the dependency
> stuff on its own (or rather, in a library; I have no clue whether it
> makes sense to make it API compatible with libapt), so that we do not
> rely on the file system to do it.  Which is to say, we won't use the
> node that tells us about problems.  This frontend can be implemented
> and tested right now, without having a usable UnionFS and without
> knowing about the details of file systems in the Hurd.  In fact, it
> will be possible to do most of the development on GNU/Linux.
> 
> You might ask, why should we do that?  The canonical answer is:
> Because we need to do it in any case.  Even if we would have a working
> UnionFS that supports package management, the frontends would have to
> care about resolving dependencies on their own, because otherwise we
> would not even be able to tell the user which packages will be
> additionally installed when he selects a package.
> 
> As soon as UnionFS will be ready, we will be able to combine these two
> pieces.  We will have a package management frontend (or several) which
> care about everything and a UnionFS that creates a unix:ish view of
> the file system.  Manually changing the underlying hierarchy might
> mess up the consistency of the packaging system, but we will have
> something usable.
> 
> After this works, we can easiely do the Right Thing: We change the
> file system to care about problems as well, and tell us about them via
> this special node (why do symbolic expressions come to my mind every
> time I mention this node? ;-)).  This should not require to much work,
> since at this point, we will already have a library that does most of
> the work for us, and we can use this library in the file system.
> 
> Whether we modify UnionFS this way or (cleaner, but maybe just too
> slow) create a seperate PackageFS that resides in the layer below
> UnionFS is another question, and I do not have a firm opinion about it
> yet.  Using an additional layer is possible because hiding directories
> and reporting problems is independend of presenting the unix:ish view.
> As it can be seperated, I tend to say that it is more natural to do it
> this way, but using another layer for every file system access even if
> it will be needed far less than 1% of the time sounds not overly
> clever to me.  I haven't given it much thought yet.
> 
> To summarize the effects of this approach:
> - No unneeded work will be done.
> - Different parts can be worked on independently.
> - We will end up with the Right Thing.
> - Usable results will be available quickly.
> - Knowledge required to hack on it will be minimal.
> - The design looks reasonably clean to me.
> 
> Are there any objections to this strategy?  Did I overlook any major
> problems?  Any other suggestions and comments?
> 
> Cheers,
> GNU/Wolfgang
> 
> PS: Did you ever realize that ``GNU package management'' can be
> abbreviated as ``GNU pacman''? <g>
>