Bug#574729: apt: essential is not a priority. apt-get should not install essential packages by default
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. As we (claim to) support partial upgrades, if the user upgrades essential package X in stable to non-essential package X in testing, dependencies in stable and testing should already be ready for that, regardless of the user using apt or not, as apt is not the only installation method. We will surely need two releases to do it right, for example: In oldstable, it's decided that package X will become non-essential. In stable all packages that need it are required to have a dependency on it. In testing, package X may drop its essential status and everything would work, unless the user mixes packages from oldstable with packages with testing, which I don't think it would be officially supported. This is for the case in which some essential functionality is dropped. When such functionality is simply moved from one package to another one, dependencies and dummy packages allow it to be done in a single release. [...] 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. dpkg also allows you to install a package and ignore its dependencies, so apt shouldn't try to fix this? The job of APT is to prevent the user from dependency hell, essentials are here to prevent the archive from too many dependencies. If APT would stop taking care of dependencies - and essentials are the hardest form of dependencies (They are always installed, will never be removed and work even in unpack state.) - the sole idea behind APT is destroyed? 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. 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? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#574729: apt: essential is not a priority. apt-get should not install essential packages by default
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
Bug#574729: apt: essential is not a priority. apt-get should not install essential packages by default
On Mon, 22 Mar 2010, David Kalnischkies wrote:
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?
No, the situation you describe would be our problem as system integrators
for allowing such thing to happen.
As I said, apt is not the only install method, so if we are really
serious into supporting partial upgrades (and I think we are), we
could probably not drop the essential status of any given functionality
in just one release without a transition period in which we add
required dependencies on the package which is to become non-essential,
even it it's still essential.
And apt should not try to solve that problem in just one release, as
the user might be using something else.
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?
Supporting partial upgrades is the reason we will never be able to
drop an essential package in just one release. Once we realize we need
two releases, partial upgrades would not be a problem.
Following your example, if we want to make perl-base non-essential, then
we would first make a stable release in which every package which uses
its functionality has an explicit depends. After such release is made,
we can drop the essential flag in the next one. Partial upgrades, with
or without apt, would then always work.
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?
No, not exactly. Note that whenever I spoke about apt-get fixing the
system I have always used quotes around the word :-)
The package was sysvinit and the Hurd uses a different boot method,
and in fact, it booted just fine wihout sysvinit being installed.
I have still to check with the Hurd people whether sysvinit should be
really essential on this architecture or not.
The point is that this package was not present in the initial install,
and everything worked fine, so I feel that apt-get was not doing the
right thing by installing it automatically, without giving a warning,
and without even telling me installing this because it's essential.
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?
(Note: By essential I understand you mean essential and required
packages here).
Because they are already installed by default, and they are never
uninstalled by accident. Considering how difficult is to remove
an essential package, if you have a system in which some essential
package is not installed, one likely possibility that we should not
discard is that the user wanted it that way.
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?
Not every implicit dependency on an essential package is a *package*
dependency in the dpkg sense, i.e. of the type that would have to
become explicit if the package becomes non-essential.
For example, if my root partition is in ext2/ext3 format, then e2fsprogs
is essential in my system. It could well be that no package depends on it,
and no dependencies would have to be added if it was to lose its essential
status.
OTOH, if none of my partitions are in ext2/ext3 format but something
completely different, and I remove e2fsprogs because it's not essential
in my system, why in earth should e2fsprogs be forced to be installed
again and again and again?
While it is true that there might be implicit dependencies on
essential
Bug#574729: apt: essential is not a priority. apt-get should not install essential packages by default
2010/3/22 Santiago Vila sanv...@unex.es: See why I say that Essential: yes means do not remove me easily, not install me if I'm not installed? No, i don't see it. Your remove is hard to do, but okay is absolutely not what essential says: I as a package maintainer want to release a package X which depends on functional on essential package Y. I can DEPEND on the fact that it is installed, not, maybe, if the user chooses to have it still installed, maybe… NO. ALL essential packages are installed ALL the time - if i wouldn't have this guarantee i need to depend on this package explicitly - so if your interpretation would be correct the whole essential thing is useless: Marking packages which maybe (depending on the mood of the administrator) are installed or not… We already have a marker for such packages: We call them Recommends… but Dependencies are what they are: They are installed or your system is broken as the package will not (or is at least not garanteed to) work correctly without them. That a system maybe run without this or that essential package only says that this package is maybe a good candidate to be dropped from essential - not that it is a good idea to remove it from my system just because my system seems to work without it. Every newly installed package could depend on it - heck, even the remove operations of the currently installed packages could depend on it. I am never sure everything will work as nothing will check for the availability of applications from essential packages. They are just there - always. 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
Bug#574729: apt: essential is not a priority. apt-get should not install essential packages by default
On Mon, 22 Mar 2010, David Kalnischkies wrote: 2010/3/22 Santiago Vila sanv...@unex.es: See why I say that Essential: yes means do not remove me easily, not install me if I'm not installed? No, i don't see it. Your remove is hard to do, but okay is absolutely not what essential says: No, I don't say that remove is ok, but dpkg has --force-remove-essential. Are you proposing that such option is dropped from dpkg? I see your point about essential status being similar to a dependency, and I see that if apt-get tries to keep dependencies satisfied, it might seem logical to ensure that all essential packages are installed as well. In short: I can agree that apt-get behaviour might be a good default behaviour, but it does not follow that this behaviour is the only possible or acceptable one. I as a package maintainer want to release a package X which depends on functional on essential package Y. I can DEPEND on the fact that it is installed, not, maybe, if the user chooses to have it still installed, maybe? Definitely, yes, as a package maintainer you can and should depend on such fact. If the user ever removes an essential package, he deserves whatever bad thing might happen as a result, and this is not your problem as package maintainer, but also it's not necessarily your problem as maintainer of apt. The user has *all* the responsability if he chooses to remove an essential package, because in either case, removing an essential package will trigger all sort of warnings. I am complaining about the fact that apt-get seems to know what he user wants better than the user himself. I hate when packages want to read the user's mind. They usually fail at doing so. I also complain about the fact that you seem to value policy a lot more than the wishes of the user. What the user wants should have higher priority in either case. [...] That a system maybe run without this or that essential package only says that this package is maybe a good candidate to be dropped from essential - not that it is a good idea to remove it from my system just because my system seems to work without it. I agree partially. If I remove an essential package and the system runs without it, then maybe it should not be essential. But how I will know how well or bad the system runs if apt-get insist on reinstalling it again and again and again? My complain is that this feature is almost never useful: * Normally, essential and required packages are already installed. * They are never removed by accident. * If they are ever removed, it's likely that the user decided to remove them. * If apt-get works at all after removing an essential package, then the user can apt-get install it himself, he does not need apt-get to do it for him. In this case the feature does not help a lot. * If apt-get does not work anymore after removing an essential package, then the automatic installation of essential packages feature is also useless, as apt-get does not work anymore. So: In which circumstances is this feature really useful to the point that it must be *forced* on the user against his will? (We have already seen than adding packages to the essential package set is easy without it, so that problem is already solved). -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#574729: apt: essential is not a priority. apt-get should not install essential packages by default
On Sun, Mar 21, 2010 at 04:36:59AM +0100, Santiago Vila wrote: Julian Andres Klode escribió: forcemerge 177952 574729 thanks On Sat, Mar 20, 2010 at 04:27:14PM +0100, Santiago Vila wrote: Package: apt Version: 0.7.25.3 It seems apt-get installs new essential packages by default. This *is* a bug. Please let me explain why: It is not, read Policy section 3.8: Essential is defined as the minimal set of functionality that MUST be available and usable on the system at all times [...] Packages may assume that functionality provided by essential packages is always available without declaring explicit dependencies If apt were not installing them, those packages would not be available on the system (1st part) and packages could not assume that they are available (2nd part). Thus, not installing all essential packages would violate the Policy and may result in a broken system. No, you are drawing conclusions that are not in policy. apt-get would not violate policy, because policy does not say that apt-get should try to fix the system. It only tries it in dist-upgrade or when installing new packages; and not on upgrade. And thus it's not fixing the system; but just ensuring that everything needed is there before doing distribution upgrades or new installations. Otherwise, changing the essential package set would be a much more difficult thing. Usually, essential and required packages are installed because debootstrap installs them in the very first system install, and also because it is difficult to remove them. So in practice it is not, and it has never been necessary for apt-get to install them. If the user does dpkg --force-remove-essential, whatever breakage that may result is entirely under the responsability of the *user*, not the responsability of apt. Moreover, quoted section 3.8 is just a description of essential, not a description of how package managers should behave. For a description of what the package system should do, we might also read section 5.6.9: 5.6.9. `Essential' -- This is a boolean field which may occur only in the control file of a binary package or in a per-package fields paragraph of a main source control data file. If set to `yes' then the package management system will refuse to remove the package (upgrading and replacing it is still possible). Please note that it says refuse to remove the package (which in practice it translates into making particularly difficult to remove it), it does *not* say the package management system should *reinstall* it again at the smallest chance! If dpkg allows the user to remove an essential package (using an extra option), apt should not second-guess the will of the user, at least not automatically, and definitely not without asking first. Keeping the integrity of the system might be a desirable and nice thing in some cases, but it's not something that should be done *against* the will of the user! You can prevent the installation of new essential packages by pinning them to -1: Package: test-essential Pin: version 0.0-0 Pin-Priority: -1 Thus I'm also closing bug #177952; because it is possible to suppress installation of essential packages. Due to Bug #216768 this may not always work in practice; but I have not checked it further. Anyway, this bug is done. -- Julian Andres Klode - Debian Developer, Ubuntu Member See http://wiki.debian.org/JulianAndresKlode and http://jak-linux.org/. pgp6pVkkvM5tL.pgp Description: PGP signature
Bug#574729: apt: essential is not a priority. apt-get should not install essential packages by default
On Sun, 21 Mar 2010, Julian Andres Klode wrote: No, you are drawing conclusions that are not in policy. apt-get would not violate policy, because policy does not say that apt-get should try to fix the system. It only tries it in dist-upgrade or when installing new packages; and not on upgrade. Ok, that's a lot better than doing it unconditionally, but still not enough as it's second-guessing the user wishes. And thus it's not fixing the system; but just ensuring that everything needed is there before doing distribution upgrades or new installations. I would not mind if apt-get did that after a simple Yes/No question, even if the default is Yes, for example: The following essential and required packages will be installed: foo Do you want to continue [Y/n]? But apt-get does nothing of the sort, so, yes, it's fixing the system, and it's overriding the user decision to remove an essential package with dpkg --force-remove-essential. I agree that fixing the system may sometimes be a good thing, my point is that it should not be forced and it should not necessarily be the default behaviour. Otherwise, changing the essential package set would be a much more difficult thing. No, that's not true, and I wrote specifically about this case in the initial message for this bug report. The truth is that it has never been a difficult thing: Whenever new essential packages have been added to the system, a dependency on an already essential and required package has been always added. Normally, the package which has a closer functionality to that of the new essential and required package is chosen to carry the dependency. If no package is particularly suitable for this, base-files could be used as a last resort. Conversely, when we want to drop (not add) an essential package, we make it a dummy package first, for one release, like mktemp in squeeze. Ironically, what apt-get does in practice regarding the essential package set is to make it really tricky to change it, i.e. the opposite of what you said. See Bug #544481 for example, where the user wants to get rid of diff, no longer essential in squeeze. He can't because apt-get insist on considering diff as an essential package. So, I see cases where this apt-get behaviour is harmful, and I have yet to see a case where this apt-get behaviour has been actually required to change the essential package set (required in the sense that we can't deal with the change using new dependencies or dummy packages). Keeping the integrity of the system might be a desirable and nice thing in some cases, but it's not something that should be done *against* the will of the user! You can prevent the installation of new essential packages by pinning them to -1: Package: test-essential Pin: version 0.0-0 Pin-Priority: -1 That is better than nothing, but does not solve the problem. The user who has already used dpkg --force-remove-essential should not have to do that. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#574729: apt: essential is not a priority. apt-get should not install essential packages by default
On Sun, Mar 21, 2010 at 02:02:19PM +0100, Santiago Vila wrote: On Sun, 21 Mar 2010, Julian Andres Klode wrote: No, you are drawing conclusions that are not in policy. apt-get would not violate policy, because policy does not say that apt-get should try to fix the system. It only tries it in dist-upgrade or when installing new packages; and not on upgrade. Ok, that's a lot better than doing it unconditionally, but still not enough as it's second-guessing the user wishes. And thus it's not fixing the system; but just ensuring that everything needed is there before doing distribution upgrades or new installations. I would not mind if apt-get did that after a simple Yes/No question, even if the default is Yes, for example: The following essential and required packages will be installed: foo Do you want to continue [Y/n]? But apt-get does nothing of the sort, so, yes, it's fixing the system, and it's overriding the user decision to remove an essential package with dpkg --force-remove-essential. I agree that fixing the system may sometimes be a good thing, my point is that it should not be forced and it should not necessarily be the default behaviour. Otherwise, changing the essential package set would be a much more difficult thing. No, that's not true, and I wrote specifically about this case in the initial message for this bug report. The truth is that it has never been a difficult thing: Whenever new essential packages have been added to the system, a dependency on an already essential and required package has been always added. Normally, the package which has a closer functionality to that of the new essential and required package is chosen to carry the dependency. If no package is particularly suitable for this, base-files could be used as a last resort. AFAIK, something like this is not required. Conversely, when we want to drop (not add) an essential package, we make it a dummy package first, for one release, like mktemp in squeeze. Ironically, what apt-get does in practice regarding the essential package set is to make it really tricky to change it, i.e. the opposite of what you said. See Bug #544481 for example, where the user wants to get rid of diff, no longer essential in squeeze. He can't because apt-get insist on considering diff as an essential package. Bug #544481 is a completely different bug; namely that packages are flagged essential instead of specific package versions. In my opinion, that one is a real bug; and apt should just allow to remove diff (although it would then reinstall it again; unless it is pinned to -1). Keeping the integrity of the system might be a desirable and nice thing in some cases, but it's not something that should be done *against* the will of the user! You can prevent the installation of new essential packages by pinning them to -1: Package: test-essential Pin: version 0.0-0 Pin-Priority: -1 That is better than nothing, but does not solve the problem. The user who has already used dpkg --force-remove-essential should not have to do that. Well, if you force dpkg to remove it, you can also just force APT to not re-install it again. -- Julian Andres Klode - Debian Developer, Ubuntu Member See http://wiki.debian.org/JulianAndresKlode and http://jak-linux.org/. pgpP4OG8LxHPJ.pgp Description: PGP signature
Bug#574729: apt: essential is not a priority. apt-get should not install essential packages by default
On Sun, 21 Mar 2010, Julian Andres Klode wrote: On Sun, Mar 21, 2010 at 02:02:19PM +0100, Santiago Vila wrote: Otherwise, changing the essential package set would be a much more difficult thing. No, that's not true, and I wrote specifically about this case in the initial message for this bug report. The truth is that it has never been a difficult thing: Whenever new essential packages have been added to the system, a dependency on an already essential and required package has been always added. Normally, the package which has a closer functionality to that of the new essential and required package is chosen to carry the dependency. If no package is particularly suitable for this, base-files could be used as a last resort. AFAIK, something like this is not required. Please elaborate. What is not required, exactly? In the diff-diffutils rename, for example, yes, it was required that diff becomes dummy and non-essential, otherwise there would not be a way to remove it. A conflicts and replaces in diffutils would not work, as that way there would be a time window in which the functionality is not present at all (details for this in Bug#563895 at the very end). So, I repeat: Please tell me a case where apt-get is required to act as it currently does for which dependencies and dummy packages (that we have always used otherwise) are not enough. Conversely, when we want to drop (not add) an essential package, we make it a dummy package first, for one release, like mktemp in squeeze. Ironically, what apt-get does in practice regarding the essential package set is to make it really tricky to change it, i.e. the opposite of what you said. See Bug #544481 for example, where the user wants to get rid of diff, no longer essential in squeeze. He can't because apt-get insist on considering diff as an essential package. Bug #544481 is a completely different bug; namely that packages are flagged essential instead of specific package versions. In my opinion, that one is a real bug; and apt should just allow to remove diff (although it would then reinstall it again; unless it is pinned to -1). They are different, but not completely different, please see: Bug #544481 says that apt-get considers a package essential if any of their available versions is essential. 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). So, no, these bugs are not so different IMHO. 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. Moreover, the algorithm of installing an essential package just because they are essential is not consistent: In the e2fsprogs/e2fsprogs-foo example, why would apt-get install one of them and not the other? Just because one of them is required and the other is extra? Then apt-get would be treating the essential status as a priority, which is not, it's just a flag which means do not let the user to remove me easily if I'm installed. Nothing less, but nothing more. Keeping the integrity of the system might be a desirable and nice thing in some cases, but it's not something that should be done *against* the will of the user! You can prevent the installation of new essential packages by pinning them to -1: Package: test-essential Pin: version 0.0-0 Pin-Priority: -1 That is better than nothing, but does not solve the problem. The user who has already used dpkg --force-remove-essential should not have to do that. Well, if you force dpkg to remove it, you can also just force APT to not re-install it again. True, but in a well integrated system the user should not have to tell things twice. BTW: I have just made this experiment in a lenny system: dpkg --force-remove-essential --purge mktemp echo mktemp hold | dpkg --set-selections apt-get dist-upgrade and this time apt-get does not automatically install mktemp. Is there a way to do the --purge and --set-selections at the same time? This is better than I expected, but still I consider apt-get buggy for installing a package just because it's essential. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#574729: apt: essential is not a priority. apt-get should not install essential packages by default
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. Consider a case in which an essential flag is dropped without an replacement - e.g. then perl-base is no longer required to be essential. If you have multiple sources you most likely have also packages from multiple releases - so some older packages maybe depend implicitly on perl-base, you can't tell me which packages does this, can you? (And yes, i still think it is silly that users want to remove obsolete packages but don't want to remove obsolete sources list entries…) 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? dpkg also allows you to install a package and ignore its dependencies, so apt shouldn't try to fix this? The job of APT is to prevent the user from dependency hell, essentials are here to prevent the archive from too many dependencies. If APT would stop taking care of dependencies - and essentials are the hardest form of dependencies (They are always installed, will never be removed and work even in unpack state.) - the sole idea behind APT is destroyed… 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… … or you can wait until the next release. It should include a way to disable essentials completely or limit them to installed packages. [0] I think both modes are silly in general but i needed them sometimes for debugging multiarch and i guess they will find their users - i just hope these users are then clever enough to do the job i would never ever want to do again on my own - i have a package manager for dependency solving… Best regards / Mit freundlichen Grüßen, David Kalnischkies P.S.: After all, we are talking here about ~25 packages -- i accept bets now then the bugcount talking about essential packages exceeds the actual count of packages marked as essential… [0] http://bazaar.launchpad.net/~donkult/apt/sid/revision/1972 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#574729: apt: essential is not a priority. apt-get should not install essential packages by default
Package: apt Version: 0.7.25.3 It seems apt-get installs new essential packages by default. This *is* a bug. Please let me explain why: The purpose and meaning of the essential flag is, and it has always been should not be removed, *not* should be installed by default. Those two things might seem very similar, but they are not! The following example comes from a very old discussion about this: Consider for example a forked e2fsprogs package having a different name, say e2fsprogs-foo. This package would Conflicts and Replaces the ordinary e2fsprogs package. It would be of extra priority, as it conflicts with a required package. However, it would be also Essential: yes. That way, installing e2fsprogs-foo would remove e2fsprogs automatically, but the user would have to use dpkg --force-remove-essential to remove e2fsprogs-foo in exactly the same way it would have to do that to remove e2fsprogs. In any of these two cases, the job of dpkg (which should be also the job of apt-get) is to prevent the user from uninstalling an essential package accidentally, but clearly *not* to ensure that all essential packages are installed as e2fsprogs and e2fsprogs-foo conflict at each other and may not be installed at the same time. By installing essential packages by default, apt-get is treating the essential flag as if it were one more priority over required. That's not the case, essential is just a flag to prevent accidental remove, not a priority. Note 1: To my amazement, Bug#177952 asks for an option to disable the current behaviour and it's marked wontfix! While such option would certainly be a step in the right direction, that would not change the fact that the default behaviour is a bug! Note 2: Whenever new essential packages are added to the system, old essential packages depend on them (example: the diff-diffutils transition from lenny to squeeze), so the ability to add packages to the set of essential packages should not be considered as a good reason to keep the current behaviour. Thanks. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#574729: apt: essential is not a priority. apt-get should not install essential packages by default
forcemerge 177952 574729 thanks On Sat, Mar 20, 2010 at 04:27:14PM +0100, Santiago Vila wrote: Package: apt Version: 0.7.25.3 It seems apt-get installs new essential packages by default. This *is* a bug. Please let me explain why: It is not, read Policy section 3.8: Essential is defined as the minimal set of functionality that MUST be available and usable on the system at all times [...] Packages may assume that functionality provided by essential packages is always available without declaring explicit dependencies If apt were not installing them, those packages would not be available on the system (1st part) and packages could not assume that they are available (2nd part). Thus, not installing all essential packages would violate the Policy and may result in a broken system. Note 1: To my amazement, Bug#177952 asks for an option to disable the current behaviour and it's marked wontfix! While such option would certainly be a step in the right direction, that would not change the fact that the default behaviour is a bug! As this bug does not contain any real different problem description, and that other bug is similar, I will merge them. -- Julian Andres Klode - Debian Developer, Ubuntu Member See http://wiki.debian.org/JulianAndresKlode and http://jak-linux.org/. pgpooUfx3SEoF.pgp Description: PGP signature
Bug#574729: apt: essential is not a priority. apt-get should not install essential packages by default
Julian Andres Klode escribió: forcemerge 177952 574729 thanks On Sat, Mar 20, 2010 at 04:27:14PM +0100, Santiago Vila wrote: Package: apt Version: 0.7.25.3 It seems apt-get installs new essential packages by default. This *is* a bug. Please let me explain why: It is not, read Policy section 3.8: Essential is defined as the minimal set of functionality that MUST be available and usable on the system at all times [...] Packages may assume that functionality provided by essential packages is always available without declaring explicit dependencies If apt were not installing them, those packages would not be available on the system (1st part) and packages could not assume that they are available (2nd part). Thus, not installing all essential packages would violate the Policy and may result in a broken system. No, you are drawing conclusions that are not in policy. apt-get would not violate policy, because policy does not say that apt-get should try to fix the system. Usually, essential and required packages are installed because debootstrap installs them in the very first system install, and also because it is difficult to remove them. So in practice it is not, and it has never been necessary for apt-get to install them. If the user does dpkg --force-remove-essential, whatever breakage that may result is entirely under the responsability of the *user*, not the responsability of apt. Moreover, quoted section 3.8 is just a description of essential, not a description of how package managers should behave. For a description of what the package system should do, we might also read section 5.6.9: 5.6.9. `Essential' -- This is a boolean field which may occur only in the control file of a binary package or in a per-package fields paragraph of a main source control data file. If set to `yes' then the package management system will refuse to remove the package (upgrading and replacing it is still possible). Please note that it says refuse to remove the package (which in practice it translates into making particularly difficult to remove it), it does *not* say the package management system should *reinstall* it again at the smallest chance! If dpkg allows the user to remove an essential package (using an extra option), apt should not second-guess the will of the user, at least not automatically, and definitely not without asking first. Keeping the integrity of the system might be a desirable and nice thing in some cases, but it's not something that should be done *against* the will of the user! -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
