[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[aps-devel] Fwd: GNU package management
From: |
Robert Millan |
Subject: |
[aps-devel] Fwd: GNU package management |
Date: |
Tue, 10 Dec 2002 19:10:48 +0100 |
User-agent: |
Mutt/1.4i |
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
>
- [aps-devel] Fwd: GNU package management,
Robert Millan <=
- [aps-devel] Fwd: GNU package management, Robert Millan, 2002/12/10
- [aps-devel] Fwd: GNU package management, Robert Millan, 2002/12/13
- [aps-devel] Fwd: GNU package management, Robert Millan, 2002/12/13
- [aps-devel] Fwd: GNU package management, Robert Millan, 2002/12/13
- [aps-devel] Fwd: GNU package management, Robert Millan, 2002/12/13
- [aps-devel] Fwd: GNU package management, Robert Millan, 2002/12/13