[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:07:46 +0100 |
User-agent: |
Mutt/1.4i |
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>
>
- [aps-devel] Fwd: GNU package management, Robert Millan, 2002/12/10
- [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 <=
- [aps-devel] Fwd: GNU package management, Robert Millan, 2002/12/13
- [aps-devel] Fwd: GNU package management, Robert Millan, 2002/12/13