Re: Bug#758234: it's actively harmful
On Wed, Oct 29, 2014 at 07:30:57PM +0100, Matthias Urlichs wrote: That's obvious. What is not so obvious, to me, is why we would still want the current policy in the first place, given that everything(?) is resolved via dependencies these days. Maybe because current policy allows one to take the following set of packages: + Packages of required priority. * Packages of important or higher priority. * Packages of standard or higher priority. and all those sets are self-consistent (i.e. they don't have dependencies outside the set). I think this is a useful and nice property, but I don't know how many people rely on it. The only practical effect of these priorities I can recognize is that apt* refuses to remove Essential packages without asking a question which reminds me what the Shift key is for.¹² Minor clarification: Essential is a flag, not a priority. Essential packages are almost always required, but they may also be extra if they Conflicts/Replaces an already existing essential package, as an alternate implementation for the same functionality (not that there are a lot of packages like that, but they are not excluded by policy). In either case, it is the essential flag, not the required priority, what makes apt-get to ask you enter the phrase yes, i agree this is very bad. Thanks. -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141030105116.ga2...@cantor.unex.es
Re: Bug#758234: it's actively harmful
Hi, Santiago Vila: Maybe because current policy allows one to take the following set of packages: + Packages of required priority. * Packages of important or higher priority. * Packages of standard or higher priority. and all those sets are self-consistent (i.e. they don't have dependencies outside the set). I think this is a useful and nice property, but I don't know how many people rely on it. It certainly is useful to have these sets of packages IMHO. But the work to keep the priorities consistent is not useful when you already have a tool that adds them (and nothing else) to a set of packages when you need it, as opposed to when ftpadmin gets around to updating the override file. Minor clarification: Essential is a flag, not a priority. *Oops* Thanks. -- -- Matthias Urlichs -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141030160945.gb8...@smurf.noris.de
Re: Bug#758234: it's actively harmful
On Thu, Oct 23, 2014 at 01:37:11PM +0100, Simon McVittie wrote: I agree with your analysis, although perhaps not the wording. Maybe something like: # The priority of a package should be based on the functionality # of the package itself, and not on whether high-priority packages # depend on it. In particular, shared libraries should normally # have a low priority, even if required or essential packages # happen to depend on them. If we are going to take that route, we might just make all libraries optional as a general rule. [footnote: This ensures that a # high-priority package transitioning to a new library dependency # does not result in both the old and new libraries being installed # on new systems, due to the old library's priority remaining high.] However, I don't like the wording of the footnote. Why would the old library's priority remain high to begin with? It sounds as Lack of manpower in the FTP team forced us to change the rules about package priorities, since they did not change priorities often enough. I hope that's not the real reason behind this proposal, because that would be a problem by itself that should be addressed separately. Thanks. -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141029124144.ga4...@cantor.unex.es
Re: Bug#758234: it's actively harmful
On Thu, Oct 23, 2014 at 03:04:43AM +0200, Adam Borowski wrote: can't even be detected via automated means. Why not? -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141029124427.gb4...@cantor.unex.es
Re: Bug#758234: it's actively harmful
On 29/10/14 12:41, Santiago Vila wrote: If we are going to take that route, we might just make all libraries optional as a general rule. That seems reasonable to me, with the possible exception of the few libraries that could justify their own priority via the wtf, why isn't this installed? rule of thumb, like libc6. [footnote: This ensures that a # high-priority package transitioning to a new library dependency # does not result in both the old and new libraries being installed # on new systems, due to the old library's priority remaining high.] However, I don't like the wording of the footnote. Why would the old library's priority remain high to begin with? To have a concrete example to talk about, let's say cron (Priority: important) moves from using libstuff0 to using libstuff1. If libstuff0 and libstuff1 both come from a libstuff source package, but you have more than one apt source - e.g. stable on a mostly testing system - then your apt can still see the older libstuff0 binaries, with the important priority that was appropriate when cron/stable depended on them. I believe this means it won't automatically get rid of libstuff0? If libstuff0 and libstuff1 are in parallel stuff0, stuff1 source packages (like Gtk2 and Gtk3), it is not clear to me how the ftp team should be expected to know that libstuff0 should be demoted from important to optional, or when would be the correct time to do so. It could equally well be a core package transitioning from one command-line tool to another (dpkg moving from lzma to xz), or from command-line tool to library (dpkg's tar.xz support again), or changing its implementation to not need one of its old dependencies (systemd used to require libdbus-1-3, but has switched to its own D-Bus implementation). It sounds as Lack of manpower in the FTP team forced us to change the rules about package priorities, since they did not change priorities often enough. Is your intention that the maintainer of libstuff would track the transition and buildd status, somehow work out when libstuff0 no longer qualified for important priority, and file ftp.debian.org bugs to demote it? Or that the ftp team determine (in some hopefully automated way) that libstuff0 no longer qualifies for important, and demote it? Or what? S -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5450ec0f.8000...@debian.org
Re: Bug#758234: it's actively harmful
On Wed, Oct 29, 2014 at 01:30:55PM +, Simon McVittie wrote: On 29/10/14 12:41, Santiago Vila wrote: If we are going to take that route, we might just make all libraries optional as a general rule. That seems reasonable to me, with the possible exception of the few libraries that could justify their own priority via the wtf, why isn't this installed? rule of thumb, like libc6. Actually, we don't need a rule like that for libc6, because lots of essential packages depend on it. We would only need to say wtf, why isn't this installed? for a library that works like a plugin (i.e. a library on which no other packages depend). [footnote: This ensures that a # high-priority package transitioning to a new library dependency # does not result in both the old and new libraries being installed # on new systems, due to the old library's priority remaining high.] However, I don't like the wording of the footnote. Why would the old library's priority remain high to begin with? To have a concrete example to talk about, let's say cron (Priority: important) moves from using libstuff0 to using libstuff1. If libstuff0 and libstuff1 both come from a libstuff source package, but you have more than one apt source - e.g. stable on a mostly testing system - then your apt can still see the older libstuff0 binaries, with the important priority that was appropriate when cron/stable depended on them. I believe this means it won't automatically get rid of libstuff0? I think we don't even need to consider more than one apt source to see the problem. We could just imagine the case where a user changes stable to testing everywhere in sources.list and then upgrades to testing. Whatever solution to the problem of getting rid of unused libraries in this simplified case would probably be a solution for the case of mixed apt sources as well. If libstuff0 and libstuff1 are in parallel stuff0, stuff1 source packages (like Gtk2 and Gtk3), it is not clear to me how the ftp team should be expected to know that libstuff0 should be demoted from important to optional, or when would be the correct time to do so. A good rule to follow if we keep current policy would be that libraries should always have the lowest priority possible (but = optional) that makes the rule packages should not depend on others with lower priority values to be true. The rule would be, of course, applied independently for each distribution (stable, testing, unstable). I believe there would be plenty of room for automation here. It could equally well be a core package transitioning from one command-line tool to another (dpkg moving from lzma to xz), or from command-line tool to library (dpkg's tar.xz support again), or changing its implementation to not need one of its old dependencies (systemd used to require libdbus-1-3, but has switched to its own D-Bus implementation). I agree that there may be a lot of different cases, but many, if not most of them should probably be automated. It sounds as Lack of manpower in the FTP team forced us to change the rules about package priorities, since they did not change priorities often enough. Is your intention that the maintainer of libstuff would track the transition and buildd status, somehow work out when libstuff0 no longer qualified for important priority, and file ftp.debian.org bugs to demote it? AFAIK, that's what we are already doing, except that it's not always the maintainer of libstuff the one who tracks the priorities to be changed and submit the bugs. Or that the ftp team determine (in some hopefully automated way) that libstuff0 no longer qualifies for important, and demote it? Or what? I think some automation on this issue would benefit everybody, yes, at least while we keep the current rules regarding priorities. My point is that there may be legitimate and valid reasons to change the rules about priorities, but we didn't automate enough should not be one of them. Thanks. -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141029153705.ga8...@cantor.unex.es
Re: Bug#758234: it's actively harmful
Hi, Santiago Vila: A good rule to follow if we keep current policy would be that libraries should always have the lowest priority possible (but = optional) that makes the rule packages should not depend on others with lower priority values to be true. That's obvious. What is not so obvious, to me, is why we would still want the current policy in the first place, given that everything(?) is resolved via dependencies these days. The only practical effect of these priorities I can recognize is that apt* refuses to remove Essential packages without asking a question which reminds me what the Shift key is for.¹² … but let's release Jessie first. ① When a terminal window is set to mouse mode, you need to press Shift if you want standard copy+paste behavior. ② Other than writing capital letters, of course. -- -- Matthias Urlichs -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141029183056.ga8...@smurf.noris.de
Re: Bug#758234: it's actively harmful
On 23/10/14 02:04, Adam Borowski wrote: Thus, I propose not merely removing this policy requirement, but also replacing it with the opposite: # A package should not (must not?) elevate its priority just because it's # depended on unless it has extra functionality that itself warrants a given # priority. I agree with your analysis, although perhaps not the wording. Maybe something like: # The priority of a package should be based on the functionality # of the package itself, and not on whether high-priority packages # depend on it. In particular, shared libraries should normally # have a low priority, even if required or essential packages # happen to depend on them. [footnote: This ensures that a # high-priority package transitioning to a new library dependency # does not result in both the old and new libraries being installed # on new systems, due to the old library's priority remaining high.] An example: * udev is depended on by P:important packages, yet creation of /dev/ nodes is something that by itself matches the definition of P:important[1] * libudev1 does nothing but serve packages that depend on in These make excellent examples. The cluster of packages around init, systemd and dbus is another interesting one. systemd is non-Essential, but is *transitively* Essential as one of several alternative dependencies for init. That makes the current policy somewhat unclear: does init's priority propagate to systemd-sysv, sysvinit-core, upstart, or none of them? At the moment, init is required, the first dependency option (systemd-sysv) is merely important (not actually enough for Policy compliance, but presumably chosen because required priority would harm the ability to switch away from systemd), and the others are extra. Meanwhile, if I'd bumped up the priority of libdbus-1-3 because systemd used to depend on it, newly debootstrap'd chroots (including those that have sysvinit-core!) would probably still be getting libdbus-1-3 even though systemd no longer needs it. S -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5448f677.4010...@debian.org
