On Wed, Jul 26, 2006 at 04:41:37PM +0200, Goswin von Brederlow wrote:
> Andreas Barth <[EMAIL PROTECTED]> writes:
> > * Ian Jackson ([EMAIL PROTECTED]) [060726 13:18]:
> >> But, for example, foo <-Depends-> foo-data is not usually an example
> >> of a silly dependency.
> >
> > Actually, there is no reason why foo-data needs foo configured before
> > being configured, but there might be reason for the other direction.
> > Why not inventing some new "Depends-for-being-useful" from foo-data to
> > foo, and having Depends cycle-free?
>
> Pre-Depends: Needs to be unpacked and configure before me
> Depends: Needs to be configured before me
>
> How about adding:
>
> Post-Depends: Needs to be configured for me to be useable
>
> The difference between Depends and Post-Depends would be that only the
> former may use the other package in the maintainer scripts.
>
>
> To implement this dpkg would need a new state. One between
> unconfigured and installed, say post-config or configured. Packages
> would go from purged to unpacked (unpacking done) to configured
> (maintainer scripts have been run) to installed (Post-Depends have
> been configured).
Adding a new state would break a lot of tools, and require a couple
of releases until it's functional.
What about this:
"Post-Depends:"/"Needs:" don't have to be satisfied for a package to
be configured. If A "Needs:" B, you can still have A installed
without B, and have a perfectly functional system -- from dpkg's
point of view.
Apt and the frontends which understand the new field will scream at
you, and won't allow such a case to happen (unless forced).
If you have a mixed system where some tools know about the new field
and some which don't, you may end up with left-over cruft like
foo-data installed without foo. This is not a problem except for
some disk space wasted -- you do have useless files on your
filesystem, but they have otherwise no detrimental effect.
This way, you could have this in for Etch.
Here's how existing tools handle the field:
dpkg-gencontrol: warning: unknown information field `C Needs' in
input data in general section of control info file
(and the field gets weeded out of the .deb)
dpkg -- no problems -- ignores it but stores
apt -- no problems (ignores it)
So, even backports would be covered with an acceptable failure mode.
> Post-Depends cycles could be broken by allowing: A package can go from
> configured to installed when all its Post-Depends are configured or
> installed. Or Post-Depends cycles are just required to be transitioned
> as one, no splitting by apt-get into multiple calls allowed.
In my proposal, apt wouldn't require to pass this to dpkg in any
special way. It would just install B whenever A is selected for
installing, and remove A if you ask for removing B, without dpkg
knowing why this is done.
Cheers and schtuff,
--
1KB // Q: How do you spot a good inetd?
// A: It build-depends on equivs.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
