On Sat, Aug 02, 2014 at 06:43:00PM +0200, Axel Beckert wrote: > David Kalnischkies wrote: > > > When doing dist-upgrades from oldstable to stable, I do them in very > > > small bits, so that no service has a downtime longer than necessary. > > > One of these steps usually includes bigger bunches of libsomething > > > packages which I surely never want to have the "automatically > > > installed" mark removed. (aptitude has one or more bugs which causes > > > that and it's already very annoying. But at least it doesn't do that > > > on purpose unless explicitly requested.) > > > > This is a pretty unusual thing to do, > > I disagree here: I know quite a bunch of server administrators > (including several DDs, Rhonda comes to my mind :-) which consider > this the _only_ way to properly dist-upgrade a server while running. > And yes, of course, the release notes only cover the all-at-once case > -- which is not suitable in all situations. > > It may be less usual for one's own desktop system where a service > downtime is not that critical, though, or generally less experienced > users. As said, I don't doubt that people are doing it, it is just that it is not the default/recommended way of doing it, so it is also not the default mode of operation. > > I think active management is something aptitude users are more or less > > used to, as an interactive tool allows to deal with that easily, while > > a tool like apt-get, but also the higher-level tools like the various > > now-called software stores are expected to provide the perfect solution > > on first try without any tweaking – as the user either doesn't want or > > simply can't do the tweaking. > > Then again apt-get isn't an App Store. Luckily. :-) Well, it is… It lacks the graphic "clickiness" of course, but you will agree that you don't (usually) do fine-grained choosing in the dependency tree, but 'apt install foo' and hit y(es). If you would, you would be using something with more feedback (like aptitude). You e.g. get no choice regarding which version to install. A successful execution of 'apt install foo' will result in foo being installed in the candidate version, regardless of it is was already up-to-date, needed to be upgraded or was an entirely new install (which is also why 'install' combines "install new package" and "upgrade existing package") similar to how you click on the install/run button in an app store and it will be there and optionally executed. > > I think you will agree that not everyone in the world is doing local > > metapackages. > > Yes. But that was just an example. The issue is neither limited to > metapackages nor to local metapackages: > > # apt-get upgrade libc6 > Reading package lists... Done > Building dependency tree > Reading state information... Done > Calculating upgrade... libc6 is already the newest version. > libc6 set to manually installed. > [...] > > # apt-get install libc6 > Reading package lists... Done > Building dependency tree > Reading state information... Done > libc6 is already the newest version. > libc6 set to manually installed. > [...] What is the problem with that? Do you say that because libc6 is a library and therefore should be always auto-installed, no matter what? If so, people will disagree with you… (think third-party binaries, compiling yourself, …). (see also next one) > > And do you really think it is that surprising that if you manually > > request the installation of a (new version of a) package that it > > isn't marked as "automatically installed" anymore? > > Yes. > > > After all, you manually installed it… > > No. I had to use "apt-get install $pkg" just because that's the > official (and only) way to upgrade a single package with pure APT. So > that was no "manual installation" request at all. As mentioned later in the previous mail, there are options to upgrade a single package, but that isn't the default mode of operation. If I understand the ancient records correctly, apt was supposed to replace specifically crafted upgrade scripts as upgrades of packages had to be done in a specific order by a human before. With this backstory, apt always has a whole-world approach to everything and in this world-view a "upgrade only a single package" simply doesn't exist. The whole point was to get away from "first upgrade this, than this and than that" mentality after all! In this mentality, seeing a package name on the commandline means the user explicitly cared for this package to be installed (in the candidate version) and hence will miss it if apt goes on and autoremoves it as if he would just be interested in a (security)bug-free system he would just do a (dist-)upgrade. Or in other words: While aptitude has a similar commandline interface, it has a different mentality – so while they are 100% compatible, they aren't exchangeable… (would be boring if they were, right?). > > It was more a remark on how untested partial upgrades usually are, > > so that it isn't unlikely that someone forgot to raise a >= on a > > -common/-data/-whatever package. > > >From my experince these issues were quite seldom in the past few > Debian Stable releases. I only remember one case of a missing > versioned dependency from Squeeze to Wheezy. (But already forgot which > package was affected. :-) Try the same on unstable/testing. Or install packages from there on stable/some derivative. Not that this would be a recommend way of doing things, but people do it and expect it to work – much like you will be the "personal friend" of many DDs if you tell them that they should just enable recommends (and read the debian-policy) [as a comment to another paragraph in your mail]. As one simple datapoint: I tend to forget ensuring a fitting version sync between libapt and apt (as the later depends on the former, but the former needs the later for some operations – fun in circles) and I doubt I am the only one. > > It is also a remark on how people think they have installed a > > security fix by installing pkgA, while the fix is actually in > > libobscureA… > > O.o While I can imagine that people don't exactly know in which > dependency the actual issue is located, I can't believe that people > really try to fix issues that way. I was indeed thinking about OpenSSL here, but that also frequently happens if we have a security bug in apt, which is in fact in libapt. I doubt it is much different for any source package building more than one package if they don't happen to have a =-relation. I would bet a fair bit of money that this was a(nother) reason to adopt the 'all or nothing' mentality in apts design back then. Best regards David Kalnischkies
Attachment:
signature.asc
Description: Digital signature