2010/3/22 Santiago Vila <sanv...@unex.es>:
> On Sun, 21 Mar 2010, David Kalnischkies wrote:
>> 2010/3/21 Santiago Vila <sanv...@unex.es>:
>> > This is a bug because, for example, once you upgrade an essential
>> > package like the real diff to a non-essential one like the dummy diff,
>> > the old essential package should not be considered essential anymore,
>> > even if it's available, i.e. it is the *currently* installed packages
>> > the ones that decide which packages are essential, not the old available
>> > ones, but for the same reason, not the *new* available ones either
>> > (which is what I am complaining about).
>>
>> And in which way apt should know that you no longer have a package from
>> e.g. stable which requires the functionality of package X which is in testing
>> no longer essential? The closest match is that if you removed the sources
>> for stable you have fully upgraded to testing.
>
> apt does not know such thing, and I don't think it is supposed to know.
> IMHO, it should only care that currently installed essential packages
> are not removed without a strong force option (like the one that asks
> the user to write "yes i know this is bad" or something alike).
> Upgrading them is always ok.
I will further enlarge my example: Imagine you have a stable system with
perl-base essential and you install a perl application from testing which
also pulls in a newer non-essential perl-base. Remove the perl application
now and run autoremove (aptitude will do this automatically by default) -
APT will remove perl-base as it is not essential and no (installed) package
depends on it (explicitely). That you break even parts of dpkg with this
move is your personal problem then, i guess…
Think also about the situation in between the upgrade - essential packages
can't be removed - but other packages can be removed in between an
upgrade if required: If your system is in the middle of the upgrade, is
the package now essential or not - and will a {post,pre}rm scripts need it?
>> > This is the reason policy says that an essential package should not be
>> > removed easily but it does not say that all essential packages should
>> > be installed automatically.
>> I would be really interested in the difference. If you haven't removed it,
>> why apt wants to reinstall it then?
>
> I discovered about this apt-get "feature" by installing The Hurd on kvm
> recently, since you ask. The default system did not include a package which
> has
> the essential flag, and to my surprise it was installed automatically, without
> asking, and without having the chance to say "no". I felt dissapointed.
So your hurd kvm install was broken: packages which require the missing
essential package can't use it and you complain now that APT tries to fix
this for you?
> I never said that installing essential packages is always bad. My point
> is that it should not be done automatically, as the letter of policy
> does not dictate such thing.
>
> Either the user is asked about it or maybe a short message is
> displayed explaining why additional packages are installed.
Why APT need to specifically ask for installing the essential packages?
Essential packages are considered to be always installed as no package
need to depend on it explicitly. So if the package is not installed you have
a broken dependency for theoretical every package - and as APT doesn't
like broken dependencies it will fix it. Would you also complain if the
package would be a "normal" dependency? Essentials are dependencies,
they are just not written down explicitly…
>> What you could try with your package is Provide+Conflict+Replaces the
>> essential package - apt will not come up with a solution to this "problem"
>> itself as we will have a (short) time frame in the transition in which no
>> package is installed providing the functionality so you still have to go over
>> dpkg force flags, but at least in theory apt should notice with the provides
>> that a package with this functionality is installed after that.
>> Another thing you can try is installing a dummy package with this name
>> and an exorbitant high version number?
>
> Sorry, I am a little bit lost here. To which problem the last
> paragraph is a suggested solution?
I suspect the e2fsprogs-foo package is from you as i haven't such a package
available, that is why i added this remarks. I could have also added that
some discussions are ongoing to drop e2fsprogs from essential, but i guess
you already know that.
Best regards / Mit freundlichen Grüßen,
David Kalnischkies
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
