Control: notfound -1 0.9.9.1~ubuntu3 Control: found -1 0.9.9.1 Control: forcemerge 731520 -1 Hi, On Tue, Feb 25, 2014 at 08:41:57PM -0800, Dan Razzell wrote: > dependencies either and installing those, /provided/ the version happens to > be the latest available in the repo. The 'candidate' version which apt can choose for installation is chosen by the pin assigned to a version. Have versions an equal pin the higher version number wins. See man 5 apt_preferences. So you are arguing against a fundamental design decision here… In other words: Your problem doesn't exist in the first place or is 'easily' solved by pinning. The rational for this (beside that it reduces the problem space A LOT) is that a release contains only one (good) version for each package as upgrades make no sense otherwise. If you want different versions of a software in your archive, you have them either in different releases or you provide versioned packages. Either way, there is a sane way to argue about upgrades then as users can follow a clear path to get (security) upgrades. Or are you really expecting your users to upgrade with apt-get install Y=x.y.z each time? Now, that I said that, there are certain cornercases were it indeed makes sense to have (temporary!) multiple versions in a release to allow packages to be installed. arch:any -> arch:all and M-A:same packages come to mind. Implementing this is tricky though as there is the danger that it prevents certain upgrades forever… (merging with the last bug I remember requesting this, there are more) > as requested, at the version requested. We think it should. The cause > will probably turn up as nothing more than one or two lines of bad logic. This is like saying "cloud is easy, as there are so many in the sky." Someone who claims to be a DevOps should know by own experience that it is silly to say such things without having knowledge about the project… Anyway: We think you should just give us your two lines patch. It will probably turn up as nothing more than one or two minutes of good work. > 8) This issue occurs on a variety of Ubuntu versions from 12.04 precise > to latest. You have noticed that this isn't Ubuntus bugtracker, right? It applies to Debian as well in this case, but you give no indication that you have tried it and you report it against Debian with an incorrect version causing trouble for the bugtracking system… (not talking about the severity inflation and not looking for dups…) Again, from someone with fancy titles, I would expect more. (sry if all that sounds aggressive, I am just returning the "favor" as I read it, even if I realize that it was probably not meant that way) Best regards David Kalnischkies, CEO of a computer science student lifeform incorporated
Attachment:
signature.asc
Description: Digital signature