On Tue, 14 Apr 1998, Juan Cespedes wrote: > > First, you must accept these three points - they describe some of how > > things operate: > > > > When a package is in the unpacked state dependencies are automatically > > severed. That is dpkg --deconfigure libreadlineg2 makes bc unusable. > > This is the first thing to accept. > > > > Wen a package has unmet dependencies it can be deconfigured, removed > > and upgraded. That is, the *rm scripts must function. This means that the > > *rm scripts can not depend on any dependencies being true. > > This validates the action of removing packages with unmet dependecies. > > > > The only things that inhibit unpacking are items that are strictly > > forbidden - violating a conflicts and unmet forwards predepends. > > So you say I should treat "depends:" and "pre-depends:" in a > different way. Well, that is an option. Many of the bug reports > about this are about ensuring we shouldn't leave "bash" unuseable by > installing an old version of libreadlineg2. (bash is essential, and so > it predepends on libreadlineg2 (>= some version)).
Read that again carefully. This section describes how things work NOW - not how you should make them work. Notice I specificly said 'forwards predepends' - that excludes reverse predepends - it is perfectly fine to unpack a new package and wreck a predepend on it (reverse predepend). > If someone (mistakenly) tries to install a version of a program which > can make an essential program fail, dpkg should not allow them to even > unpack that program. However, By that logic It shouldn't allow someone to install a version of a program and leave it unconfigured - BUT IT DOES! dpkg does very little to protect essential packages. > > If you don't like one of the above then that is a separate issue, but give > > your argument alot of consideration first, they are how things have been > > working for quite a long time. > > No, they aren't done that way now. That's why I wanted to fix > it. In the current version, dpkg can left Pre-Dependencies unmet > without even a warning. Please tell me exactly how and which of the three points above are not true now - it's very important. Check your facts, because I have verified each of the above. > > Lets unpack libreadlineg2 2.1-9. Once we do that bc stops working (point > > #1) however we can safely alter bc's state (point #2) > > > > Now, lets look at your case, unpack libreadlineg2 2.1-3. Once we do that > > bc stops working (point #1 combined with the unmet dependency) however > > again, we can safely alter bc's state. > > > > Notice that both actions have identical results on the system. > > Yes, but in one of the cases, bc will no longer work (even > after configuring libreadlineg2) because it depends on a version of > libreadlineg2 that is not installed. That is an irrelivent point - at the time of unpacking dpkg cannot be assured that libreadline will ever be configured or even that it can be configured. > It will work after configuring libreadlineg2. See, this is the entire flaw in your reasoning - dpkg was specificly designed so that each action is concerned only with it's own effects and not th effect on the system as a whole. When unpacking, dpkg cannot know that the package is configurable, it was actually specificly designed to ALLOW the case of unpacking an unconfigurable package. Though you are right that 'after configuring libreadlineg2 bc will work' but you cannot say that libreadlineg2 can ever be configured so the statement is pointless as a justification for differentiating the two cases. To see what I mean think about this: A new bc will be installed that depends on the new libreadlineg2 Wow - I just justified why you should not bother checking that unpacking the new libreadlineg2 broke bc because it will be 'ok later'. Of course I can't prove that in all cases bc will be installed. You also can not prove that libreadelineg2 will ever be configured. > > Now, lets consider the possibility of applying a deconfigure step so that > > all configured packages are always working. > > I don't want them to be always working. However, I would like > to have them working after configuring all the packages. dpkg has no decision point where it can say this about anything, and again you are operating under the strange idea that configuring has something to do with the decisions at the unpacking phase - if this were so it would look at normal depends while unpacking. > > When I unpack libreadline2g > > (any version!) I will have to deconfigure bash (!!), bc and others so that > > they are never configured and not working. > > bash will never be deconfigured unless the > "--force-remove-essential" flag is set. > > Obviously this is not possible, upgrading something like libc6 would > > cripple the entire system. > > What will break? What packages depend on a specific version > of libc6? Only libc6-dev and libc6-doc. (BTW: the libc6-doc > dependency has been reported as Bug#21045). Well, you see, this was a thought example, go re-read my original email. The point of this section was to illistrate that checking for reverse dependencies is only a small portion of the total puzzle to ensuring a system that always works. To do it completely requires the actions I go on to suggest and explore. You are supposed to appreciate that you are not adding much in the way of safety with your new check. > However, if someone tries to downgrade libc6 to, say, version > 2.0.4, dpkg shouldn't let you do it because sysvinit has a line > "Pre-Depends: libc6 (>= 2.0.5c-0.1)". PreDepends are irrelevent at any point other than the unpacking phase [as is now] if you change the meaning you should really discuss it on policy. > > Trying to fix only one situation does virtually nothing for the > > stability of the system > > It prevents many errors. Try installing "libreadlineg2_2.0-1" > and see how bash stops working without even a warning. Try unpacking libreadlineg2_2.0-10 and see how bash stops working without even a warning. dpkg allows you to do lots of things that are unsafe - why are we singaling out only one? > > The basic problem is that dpkg is not really able to deal with reverse > > dependencies because it has no idea what will happen in a few seconds - it > > has no concept of heading toward a destination and hence cannot validate > > that what it is doing is ok with respect to where it is going. > > Oh, yes, it knows what it is doing most of the time. No it doesn't, that is the real issue behind this bug: dpkg checks only what is relevent to the operation at hand and nothing more. You want to make it check things that are not relevent to the operation it is performing. This is major change of direction for dpkg. > > APT makes 0 use of any of dpkg's automatic features. Things arranged so as > > to defeat all of them. > > In this case, APT shouldn't be worried at all. If you add this check the apt will fail because it is not always possible to get the order your enforce without falling back to unconfigures and the unconfigures are not required because APT knows that the dependency will be okay a few operations down the road. > > Has anyone considered that this is not a dpkg bug - but is a feature? > > No. dpkg should check all the dependencies, or check no > dependencies at all. Checking just some of them can't be a feature. It DOES check all dependencies, quite simply reverse dependencies are not relevent to any of the stages, so it has no reason to check them. If you add checks for reverse dependencies then I think dpkg will no longer be usefull in the same sense it was before. Also, there are many other things you should enforce because they are in essence the same as checking reverse dependencies. You have to realize that in fixing this bug you take dpkg further away from being a low-level tool and closer to being an end user interface. In doing so we loose a little bit of the lowlevel tool. [And it's still a really bad user interface] Do you really think the gains in usability are worth the sacrifice of flexability? I don't think you make things much safer and you do give up quite a bit. I think it would be best just to show a warning when configuring, and make sure that audit can detect the situation. Jason -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
