Debian Bug report logs - #756816
document "apt(-get) (dist-)upgrade pkga pkgb-"

Reply or subscribe to this bug.

Display info messages

Message #5 received at [email protected] (full text, mbox, reply):

From: Axel Beckert <[email protected]>

To: Debian Bug Tracking System <[email protected]>

Subject: apt: "apt-get upgrade packagename" should not set packagename to manually installed

Date: Sat, 02 Aug 2014 02:02:50 +0200

Package: apt
Version: 1.1~exp2
Severity: normal

Dear APT Developers,

it seems that -- despite the documentation suggests otherwise -- you now
can pass package names as parameter to "apt-get upgrade" and it does
what you expect: Try to upgrade only that package.

But it also seems to set the given package to "manually installed" for
which there is no reason at all:

# apt-get upgrade zsh
Reading package lists... Done
Building dependency tree       
Reading state information... Done
Calculating upgrade... zsh is already the newest version.
zsh set to manually installed. <---------------- This shouldn't happen!
The following packages were automatically installed and are no longer required:
[…]

-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (600, 'testing'), (110, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 3.15-trunk-amd64 (SMP w/4 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages apt depends on:
ii  debian-archive-keyring  2012.4
ii  gnupg                   1.4.18-2
ii  libapt-pkg4.13          1.1~exp2
ii  libc6                   2.19-7
ii  libgcc1                 1:4.9.1-4
ii  libstdc++6              4.9.1-4

apt recommends no packages.

Versions of packages apt suggests:
ii  apt-doc     1.0.6
ii  aptitude    0.6.11-1
ii  dpkg-dev    1.17.10
ii  python-apt  0.9.3.8
ii  synaptic    0.81.2
ii  wajig       2.14

-- no debconf information

Message #10 received at [email protected] (full text, mbox, reply):

From: David Kalnischkies <[email protected]>

To: Axel Beckert <[email protected]>, [email protected]

Subject: Re: Bug#756816: apt: "apt-get upgrade packagename" should not set packagename to manually installed

Date: Sat, 2 Aug 2014 12:20:48 +0200

[Message part 1 (text/plain, inline)]

Control: retitle -1 document "apt(-get) (dist-)upgrade pkga pkgb-"

On Sat, Aug 02, 2014 at 02:02:50AM +0200, Axel Beckert wrote:
> it seems that -- despite the documentation suggests otherwise -- you now
> can pass package names as parameter to "apt-get upgrade" and it does
> what you expect: Try to upgrade only that package.

No, they don't do that, at least it is not intended. (dist-)upgrade is
performed as usual, the packages you can provide are just hints. Imagine
a dist-upgrade which has to decide between A | B and chooses A, while
you prefer B. "apt-get dist-upgrade B" will take care of this – as well
as "apt-get dist-upgrade A-" in that case.

In the past you would have to either manually upgrade certain packages
earlier or set them on hold or something to make such a choice.

Michael (git d8a8f9d7) should have documented that though.


> But it also seems to set the given package to "manually installed" for
> which there is no reason at all:

Well, there is apts usual reason: If you care enough to mention the
package explicitly on the commandline, you properly don't want apt to
suggest its removal later on.

I can't say I am a huge fan of that, but it is at least very consistent
and avoids that the autoremoval is overagressive – or do I really want
it to remove my favorite shell because it isn't needed anymore? ;)



If you want to upgrade a 'single' package, "install" is for you (which
has the exact same behavior regarding the autobit).  Partial upgrades
tend to lead to disaster, so that we see no real point in exposing them
more directly – at least not in favor of more useful cases. An
interactive tool like aptitude can do that differently of course, but we
have only the commandline available for decision making…


Best regards

David Kalnischkies

[signature.asc (application/pgp-signature, inline)]

Message #17 received at [email protected] (full text, mbox, reply):

From: Julian Andres Klode <[email protected]>

To: David Kalnischkies <[email protected]>, [email protected]

Cc: Axel Beckert <[email protected]>

Subject: Re: Bug#756816: apt: "apt-get upgrade packagename" should not set packagename to manually installed

Date: Sat, 2 Aug 2014 12:53:29 +0200

On Sat, Aug 2, 2014 at 12:20 PM, David Kalnischkies
<[email protected]> wrote:
> Well, there is apts usual reason: If you care enough to mention the
> package explicitly on the commandline, you properly don't want apt to
> suggest its removal later on.
>
> I can't say I am a huge fan of that, but it is at least very consistent
> and avoids that the autoremoval is overagressive – or do I really want
> it to remove my favorite shell because it isn't needed anymore? ;)

Could we get rid of it for the "apt" tool? We have apt-mark to set
manual/automatic, so there's not much point anymore. Especially since
this often happens by accident (at least for me, with install).

-- 
Julian Andres Klode  - Debian Developer, Ubuntu Member

See http://wiki.debian.org/JulianAndresKlode and http://jak-linux.org/.

Message #22 received at [email protected] (full text, mbox, reply):

From: Axel Beckert <[email protected]>

To: David Kalnischkies <[email protected]>

Cc: [email protected], Frank Hofmann <[email protected]>

Subject: Re: Bug#756816: apt: "apt-get upgrade packagename" should not set packagename to manually installed

Date: Sat, 2 Aug 2014 13:28:38 +0200

Hi David,

thanks for the explanations.

David Kalnischkies wrote:
> Control: retitle -1 document "apt(-get) (dist-)upgrade pkga pkgb-"

Yeah, I would have done that after your mails if you wouldn't have
done that.

JFTR: I looked IIRC in the man-page for apt-get, maybe also in the one
for apt.

> On Sat, Aug 02, 2014 at 02:02:50AM +0200, Axel Beckert wrote:
> > it seems that -- despite the documentation suggests otherwise -- you now
> > can pass package names as parameter to "apt-get upgrade" and it does
> > what you expect: Try to upgrade only that package.
> 
> No, they don't do that, at least it is not intended. (dist-)upgrade is
> performed as usual, the packages you can provide are just hints.

IMHO such a behaviour is highly non-intuitive. This is definitely a
thing where aptitude's behaviour is way more consistent
and intuitive. "aptitude full-upgrade ~slibs" just does what I mean:
Upgrade all package in the section libs without marking them suddenly
as not automatically installed.

> Imagine a dist-upgrade which has to decide between A | B and chooses
> A, while you prefer B. "apt-get dist-upgrade B" will take care of
> this – as well as "apt-get dist-upgrade A-" in that case.

Ah, that kind of hints. Should be documented at least, yes. I though
still think aptitude's behaviour is the more intuitive one.

> In the past you would have to either manually upgrade certain packages
> earlier or set them on hold or something to make such a choice.

Well, that is one of the reasons why I usually prefer aptitude for
dist-upgrades. I don't have to press Ctrl-C and think about which
packages I have to pass to apt-get to make it understand what I want.
In aptitude I can do that just interactively and I'm done. (I don't
want to start a flamewar here. I just want to point out what I used
to. It likely explains how I come to my expectations. :-)

> > But it also seems to set the given package to "manually installed" for
> > which there is no reason at all:
> 
> Well, there is apts usual reason: If you care enough to mention the
> package explicitly on the commandline, you properly don't want apt to
> suggest its removal later on.

I definitely disagree here. IMHO this is very non-intuitive behaviour.

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.)

> I can't say I am a huge fan of that, but it is at least very consistent
> and avoids that the autoremoval is overagressive – or do I really want
> it to remove my favorite shell because it isn't needed anymore? ;)

Yes!

Yes indeed. Otherwise I would not have marked it "automatically
installed". All my favourite packages are in a local metapackages. If
that metapackages drops a dependency/recommends/suggests on a package,
I want this package to be removed.

I mean, that's what the "automatically installed" mark is for! The way
apt handles it currently looks as if apt thinks it knows better than
the local admin which package got the "automatically installed" mark
for good reasons and which not. Which IMHO is clearly wrong.

> If you want to upgrade a 'single' package, "install" is for you (which
> has the exact same behavior regarding the autobit).

Which I disagree, too. For the very same reasons.

> Partial upgrades tend to lead to disaster,

Huh? Works fine for me for ages in general. Just not with apt-get but
with aptitude. ;-) That's one of things I like aptitude for a lot. And
is one of the reasons why I use apt-get so seldomly.

> An interactive tool like aptitude can do that differently of course,
> but we have only the commandline available for decision making…

Ok, maybe I'm really too much of an aptitude user to fully unterstand
that reasoning. :-D

Anyway, thanks again for all these explanations. I think, I understand
apt-get a little more than before. And IMHO it clearly shows why there
are both, apt-get and aptitude, and what's their use cases. Much
appreciated, despite my disagreement. :-)

		Regards, Axel
-- 
 ,''`.  |  Axel Beckert <[email protected]>, http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE
  `-    |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5

Message #27 received at [email protected] (full text, mbox, reply):

From: David Kalnischkies <[email protected]>

To: Axel Beckert <[email protected]>, [email protected]

Cc: Frank Hofmann <[email protected]>

Subject: Re: Bug#756816: apt: "apt-get upgrade packagename" should not set packagename to manually installed

Date: Sat, 2 Aug 2014 17:06:45 +0200

[Message part 1 (text/plain, inline)]

> > On Sat, Aug 02, 2014 at 02:02:50AM +0200, Axel Beckert wrote:
> > > But it also seems to set the given package to "manually installed" for
> > > which there is no reason at all:
> > 
> > Well, there is apts usual reason: If you care enough to mention the
> > package explicitly on the commandline, you properly don't want apt to
> > suggest its removal later on.
> 
> I definitely disagree here. IMHO this is very non-intuitive behaviour.
> 
> 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, so don't expect the defaults to be
helping you with this. The release notes are pretty specific in how you
should be doing a dist-upgrade… (more of a general remark, not specific
to this one here).


> > I can't say I am a huge fan of that, but it is at least very consistent
> > and avoids that the autoremoval is overagressive – or do I really want
> > it to remove my favorite shell because it isn't needed anymore? ;)
> 
> Yes!
> 
> Yes indeed. Otherwise I would not have marked it "automatically
> installed". All my favourite packages are in a local metapackages. If
> that metapackages drops a dependency/recommends/suggests on a package,
> I want this package to be removed.
> 
> I mean, that's what the "automatically installed" mark is for! The way
> apt handles it currently looks as if apt thinks it knows better than
> the local admin which package got the "automatically installed" mark
> for good reasons and which not. Which IMHO is clearly wrong.

Yes, and no. Active management of the autobit requires exactly that:
active management. Something not everyone wants to do. A lot of people
got really scared then they removed iceweasel and apt(itude) suggested
to remove all of gnome with it. Technically completely correct and the
solution is easy for each user, but the chosen solution in the end was
to handled metapackages differently (which isn't really nice either,
which I want to change/discuss at some point, but different beast…
I just mention it here, because some of what you think are bugs above
are probably caused by this).

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.

(which in fact is how I use apt as I usually don't have an opinion on
or-groups and stuff. I tend to check the removes – which unfortunately
many people consider optional even in unstable – but thats it. I choose
the stuff I interact with directly, for the rest I don't care…)

I think you will agree that not everyone in the world is doing local
metapackages. Or wants to deal with package management below the level
of install/remove what he likes (not). 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? After all, you manually installed it…


I think the problem is more that we try to encode everything in
a boolean flag here. In my book it would be more sensible to have more
states here and options for the autoremover to switch between shades of
"I don't want to think, please only propose something if you are really
sure" and "*I* have marked packages explicitly, the rest is fair game
for you as I will check what you propose".


> > If you want to upgrade a 'single' package, "install" is for you (which
> > has the exact same behavior regarding the autobit).

I actually lied a bit:
apt-get install pkgA --only-upgrade
will actually do what you want without changing the autobit.


> > Partial upgrades tend to lead to disaster,
> 
> Huh? Works fine for me for ages in general. Just not with apt-get but
> with aptitude. ;-) That's one of things I like aptitude for a lot. And
> is one of the reasons why I use apt-get so seldomly.

That wasn't a remark on apt-get/aptitude. 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.
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…


Best regards

David Kalnischkies

P.S.: I will be offline starting tomorrow, so don't be suprised if
I don't answer in the next ~weeks.

[signature.asc (application/pgp-signature, inline)]

Message #32 received at [email protected] (full text, mbox, reply):

From: Axel Beckert <[email protected]>

To: [email protected]

Subject: Re: Bug#756816: apt: "apt-get upgrade packagename" should not set packagename to manually installed

Date: Sat, 2 Aug 2014 18:43:00 +0200

Hi David,

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.

> > > [...] do I really want it to remove my favorite shell because it
> > > isn't needed anymore? ;)
> > 
> > Yes!
> > 
> > Yes indeed. Otherwise I would not have marked it "automatically
> > installed". All my favourite packages are in a local metapackages. If
> > that metapackages drops a dependency/recommends/suggests on a package,
> > I want this package to be removed.
> > 
> > I mean, that's what the "automatically installed" mark is for! The way
> > apt handles it currently looks as if apt thinks it knows better than
> > the local admin which package got the "automatically installed" mark
> > for good reasons and which not. Which IMHO is clearly wrong.
> 
> Yes, and no. Active management of the autobit requires exactly that:
> active management. Something not everyone wants to do. A lot of people
> got really scared then they removed iceweasel and apt(itude) suggested
> to remove all of gnome with it. Technically completely correct and the
> solution is easy for each user, but the chosen solution in the end was
> to handled metapackages differently (which isn't really nice either,
> which I want to change/discuss at some point, but different beast…

Yes, indeed. I also think the special handling of metapackages you
mentioned is the wrong way. But I do see why it's the default.

> 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. :-)

> (which in fact is how I use apt as I usually don't have an opinion on
> or-groups and stuff.

Indeed that's again a difference in how we work. I usually care about
alternative dependencies.

> I tend to check the removes – which unfortunately
> many people consider optional even in unstable – but thats it.

I must admit, I don't have much mercy for such people. (For me, that's
on a similar level as setting APT::Install-Recommends to false and
then complaining that a package doesn't work properly because of a
missing dependency for a specific feature.)

> 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.
[...]

> 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.

> I think the problem is more that we try to encode everything in
> a boolean flag here. In my book it would be more sensible to have more
> states here and options for the autoremover to switch between shades of
> "I don't want to think, please only propose something if you are really
> sure" and "*I* have marked packages explicitly, the rest is fair game
> for you as I will check what you propose".

Interesting idea. Not sure what the outcome would be, but allows for
new ideas and workflows. :-)

> > > If you want to upgrade a 'single' package, "install" is for you (which
> > > has the exact same behavior regarding the autobit).
> 
> I actually lied a bit:
> apt-get install pkgA --only-upgrade
> will actually do what you want without changing the autobit.

Thanks for that hint. Will have a look at it.

> > > Partial upgrades tend to lead to disaster,
> > 
> > Huh? Works fine for me for ages in general. Just not with apt-get but
> > with aptitude. ;-) That's one of things I like aptitude for a lot. And
> > is one of the reasons why I use apt-get so seldomly.
> 
> That wasn't a remark on apt-get/aptitude.

I know. :-)

> 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. :-)

> 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.

		Regards, Axel
-- 
 ,''`.  |  Axel Beckert <[email protected]>, http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE
  `-    |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5

Message #37 received at [email protected] (full text, mbox, reply):

From: "Adam D. Barratt" <[email protected]>

To: Axel Beckert <[email protected]>, [email protected]

Subject: Re: Bug#756816: apt: "apt-get upgrade packagename" should not set packagename to manually installed

Date: Thu, 07 Aug 2014 13:31:12 +0100

On 2014-08-02 17:43, Axel Beckert wrote:
> Hi David,
> 
> David Kalnischkies wrote:
[...]
>> 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.

While it's not precisely equivalent, there's a reason that openssl DSAs 
now include the text "It's important that you upgrade the libssl1.0.0 
package and not just
the openssl package".

Regards,

Adam

Message #42 received at [email protected] (full text, mbox, reply):

From: David Kalnischkies <[email protected]>

To: Axel Beckert <[email protected]>, [email protected]

Subject: Re: Bug#756816: apt: "apt-get upgrade packagename" should not set packagename to manually installed

Date: Fri, 15 Aug 2014 16:37:24 +0200

[Message part 1 (text/plain, inline)]

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

[signature.asc (application/pgp-signature, inline)]

Send a report that this bug log contains spam.