[aps-devel] Fwd: GNU package management

[Robert Millan]

On Sat, Nov 30, 2002 at 03:38:35PM +0100, M. Gerards wrote:
> Quoting Wolfgang Jaehrling <address@hidden>:
> 
> > 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.
> 
> This is exactly how I remember it and I agree :)
> 
> > 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.
> 
> I completely agree with you. The frontend is a must, because most
> people will use a frontend. Still we need those checks in the fs to
> make sure everything is sane because user might want to add packages
> manually. Development on GNU/Linux is a nice thing because it is more
> stable, I also do that when possible.
>  
> > 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.
> 
> Can you describe this library more detailed? If you mean analysing
> package dependancy files etc. I would agree.
> 
> > 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.
> 
> I have my doubts about a seperate layer. Before I will agree I want to
> know these things:
> 
> - How much will the file lookup process be slowed down?
> - When a new package is added will unionfs be informed of this
> - addition? (the filesystem can notify a program of changes, I don't
>   know the exact possibilities).
> - How to deal with filename collisions? (In some cases it might be
> - usefull to override a part of a package, in some case it isn't)
> 
> 
> In general the packagefs translator can be quete stupid, it just needs
> to show all unionfs directories. For this some unionfs code is
> required because netfs doesn't like this behaviour AFAIK. And
> packagefs should add a directory with information about dependancy
> problems, file name collisions, etc. It might be usefull to write down
> all features of packagefs, how they will be implemented with packagefs
> and how they will be implemented with packagefs+unionfs. Also we have
> to create a list with all advantages and disadvantages. Personally I
> don't like to lose flexibility because of development speed, although
> it would be stupid if we choose the difficult solution if there is no
> gain :).
> 
> > 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?
> 
> I think we should talk more about the design. Not because I disagree
> (which I don't), but to catch problems before writing it and to come
> up with a better design. We should also discuss kitten. I hope kitten
> can be written by a newcomer. We need developers, such simple
> translator might make someone enthousiastic about the Hurd :). I spoke
> with ^SilenT^ about this, he told me he thought about doing
> this. I discussed writing support for kitten with Wolfgang. I came up
> with the idea to use regular expressions, that might be a little
> difficult (or is there a libregexp?). Wolfgang also had some smart
> ideas, I hope Wolfgang wants to describe them :).
>  
> -------------
> Marco Gerards
>