On Sat, Feb 14, 2009 at 12:16:16PM -0800, Russ Allbery wrote: > Kurt Roeckx <k...@roeckx.be> writes: > > >> + If there is a circular dependency among packages being installed > >> + or removed, installation or removal order honoring the > >> + dependency order is impossible, requiring the dependency loop be > >> + broken at some point and the dependency requirements violated > >> + for at least one package. Packages involved in circular > >> + dependencies may not be able to rely on their dependencies being > >> + configured when being configured or removed depending on which > >> + side of the break of the circular dependency loop they happen to > >> + be on. If one of the packages in the loop has no > > > > A previous proposal had two times unpacked instead of configured, and > > I'm not really sure why you changed it. > > Based on the subsequent discussion, I thought this was more accurate, but > it's possible that I misunderstood. > > > They can't rely on it being configured, so the text is not wrong. > > > > But the previous text has atleast two other things that it indirectly > > states that you can't rely on in case of circular dependecies: > > - If you're being configured wether you're dependend-on package > > is unpacked. You now only say it's not configured. > > Why can't you rely on this?
I don't know if we can rely on it or not. > The definition of Depends says that it doesn't apply to the unpack state > at all: > > A `Depends' field takes effect _only_ when a package is to be > configured. It does not prevent a package being on the system in an > unconfigured state [...] So it can be in unpacked state, but it doesn't have to be. > Therefore, why would there ever be a situation when a package is being > configured and its dependencies aren't yet unpacked? You can always > unpack all the relevant packages first, as discussed in the next > paragraph: > > For this reason packages in an installation run are usually all > unpacked first and all configured later; this gives later versions of > packages with dependencies on later versions of other packages the > opportunity to have their dependencies satisfied. > > If this is not true, then there's something more fundamentally wrong with > the current text that needs to be fixed. I have no idea what exactly dpkg's behaviour is in case it breaks a dependency loop. Note that it says usually. It might unpack the depended-on package already, I don't know. I would say that policy atleast isn't clear on what can be expected when a dependency loop is broken. > > - When you're being unpacked that the dependend-on package is > > unpackaged which might be important to maintainer scripts. During > > the unpack state all maintainer scripts can potentially be called, > > taking the error cases into account. All but postinst can be called > > if there is no error. > > I think this is another aspect of the same point above? My understanding > from the discussion and the clarified text that Raphael sent is that > postrm can always rely on the depended-on package being unpacked and > configured and prerm can always rely on it at least being unpacked, even > in the case of circular dependencies. As I understand it, the dependency is ignored so you can not rely on anything you expect for a Depends in case of circular dependencies. Kurt -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
