Re: [RFC] DEP-6: Meta-Package debian/control field
Le 22 déc. 09 à 13:59, Rene Engelhard a écrit : Hi, On Mon, Dec 21, 2009 at 05:12:15PM +, Philipp Kern wrote: You're on your own with these. I don't think you want to go though A recommends B which depends on C which depends on D etc. route on servers which should have only the stuff installed you need. Or even on desktops which you want clean. If you want a minimalistic install, you don't want to install meta- packages either. You want to install a base Debian system plus a very few packages that you really need (without recommends) plus there dependencies. You certainly don't want Gnome or KDE or anything that means everything is suite blah. Cheers, Thibaut. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [RFC] DEP-6: Meta-Package debian/control field
David Paleino da...@debian.org wrote in message news:16193268.79mvg96...@home.hanskalabs.net... Hello people, per the DEP process described at http://dep.debian.net/deps/dep0/, this is the first call for comments on this proposal. Title: Meta-Package debian/control field DEP: 6 State: DRAFT Date: 2009-12-20 Drivers: David Paleino da...@debian.org, Luca Bruno lethalma...@gmail.com URL: http://dep.debian.net/deps/dep6 License: Copying and distribution of this file, with or without modification, are permitted in any medium without royalty provided the copyright notice and this notice are preserved. Abstract: Introduce the usage of a new field in debian/control, Meta-Package, to mark meta-packages as such, and allow easy choice of installed packages, without being bitten by the autoremove feature of package management tools. Counter proposal: New meta-package Boolean field. Meta-packages would normally have few or no Depends, being almost completely recommends. Recommends (perhaps also Depends) of meta-packages are not marked as automatically installed. Attempting to install a meta-package if apt is not configured to install recommends by default will terminate in an error, rather than completing, unless a force flag was passed. (This is to ensure the meta-package does not basically completely fail if that setting is off, without spitting out some form of error). -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [RFC] DEP-6: Meta-Package debian/control field
Joe Smith wrote: Counter proposal: New meta-package Boolean field. Meta-packages would normally have few or no Depends, being almost completely recommends. Recommends (perhaps also Depends) of meta-packages are not marked as automatically installed. The usefulness of this part of my counter proposal is debatable. It allows removing the meta-package without removing the installed packages. If that is not desired, then don't include it. That would make meta-packages special only due to the following: Attempting to install a meta-package if apt is not configured to install recommends by default will terminate in an error, rather than completing, unless a force flag was passed. (This is to ensure the meta-package does not basically completely fail if that setting is off, without spitting out some form of error). -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [RFC] DEP-6: Meta-Package debian/control field
Joe Smith unknown_kev_...@hotmail.com writes: Counter proposal: New meta-package Boolean field. Why a new field in the Packages file? This seems like an ideal use for debtags. No? -- \ “A child of five could understand this. Fetch me a child of | `\ five.” —Groucho Marx | _o__) | Ben Finney -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [RFC] DEP-6: Meta-Package debian/control field
Ben Finney ben+deb...@benfinney.id.au writes: Joe Smith unknown_kev_...@hotmail.com writes: Counter proposal: New meta-package Boolean field. Why a new field in the Packages file? This seems like an ideal use for debtags. No? It doesn't to me. The whole point of debtags is that it's crowd-edited, but whether a package is a metapackage should be under the direct control of the package maintainer. Also, debtags can change independently of the package, but the metapackage status will not change without a package upload. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [RFC] DEP-6: Meta-Package debian/control field
Russ Allbery r...@debian.org writes: Ben Finney ben+deb...@benfinney.id.au writes: This seems like an ideal use for debtags. No? It doesn't to me. The whole point of debtags is that it's crowd-edited, but whether a package is a metapackage should be under the direct control of the package maintainer. True enough. Thanks for the quick obvious answer to my poorly-conceived question. -- \ “When we talk to God, we're praying. When God talks to us, | `\ we're schizophrenic.” —Jane Wagner, via Lily Tomlin, 1985 | _o__) | Ben Finney -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [RFC] DEP-6: Meta-Package debian/control field
Hi, On Mon, Dec 21, 2009 at 05:12:15PM +, Philipp Kern wrote: You're on your own with these. I don't think you want to go though A recommends B which depends on C which depends on D etc. route on servers which should have only the stuff installed you need. Or even on desktops which you want clean. Of couse you can argue that those are bugs that should be fixed, but I fear in some cases it's not a good idea tryingt to fix this... Grüße/Regards, Rene -- .''`. René Engelhard -- Debian GNU/Linux Developer : :' : http://www.debian.org | http://people.debian.org/~rene/ `. `' r...@debian.org | GnuPG-Key ID: D03E3E70 `- Fingerprint: E12D EA46 7506 70CF A960 801D 0AA0 4571 D03E 3E70 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [RFC] DEP-6: Meta-Package debian/control field
Besides sane handling of metapackages we should also think about marking transitional packages in some way. This would enable higher level tools like apt to mark them as automatically installed and thus get rid of useless packages if no other package depends on them. The dependencies of these transitional packages would be marked as manually installed if the transitional package was marked as manually installed. deborphan tries to detect such packages by checking if a short description contains the words dummy or transitional. This hack is ok for deborphan but should not be adopted by apt. On Mon, Dec 21, 2009 at 07:52:22AM -0800, Steve Langasek wrote: This could be done with special handling of 'Section: metapackages', or by adding a new 'Metapackage: yes' field (as I think some would prefer based on comments on IRC). Instead of adding various new fields we could use debtags for non-essential information to be used by higher level packaging tools, e.g. metapackages or transitional packages. Carsten -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [RFC] DEP-6: Meta-Package debian/control field
On Wed, Dec 23, 2009 at 1:21 AM, Carsten Hey cars...@debian.org wrote: we should also think about marking transitional packages in some way. There was recently a proposal which would remove the need for transitional binary packages at all, apt would simply migrate the old package name to the new one. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [RFC] DEP-6: Meta-Package debian/control field
Steve Langasek wrote: On Sun, Dec 20, 2009 at 09:30:04PM +0100, David Paleino wrote: Ubuntu defines a special archive section, 'metapackages', which results in special tagging/handling of the Depends and Recommends of the package so that they're not autoremoved if the metapackage is removed. This is implemented in the high-level package management tools. Well, our proposal prospects something different: the metapackage is not removed (thus everything else is not autoremoved) if one of its Meta- Depends/Depends is removed. From what I can tell, the only difference between the two implementations is compatibility with disabling installation of Recommends by default. And, how do you achieve that? I mean, meta-packages should *always* have their Recommends installed, otherwise they have no point in existing. If we use Recommends instead of Depends, that becomes configurable with APT::Install-Recommends (or similar), and we totally miss the point of this DEP (and of meta-packages). I don't think this is a good rationale for adding yet another package relationship field. The Recommends field is *already* defined in Policy to have the behavior you're looking for (installed by default but not a hard requirement), and I don't see any reason that metapackages should need the added complexity of a different field. Then, how do you differentiate between genuine Recommends and meta- package Recommends? I only see two ways: Meta-Package: yes (but, like Daniel pointed out, changing the behaviour of a field basing on another doesn't seem so clean), or Meta-Depends (or whatever you want to call that). In this scenario, with Recommends installed by default (the only sane model), On my host, Recommends are not installed by default, and this is configurable. A similar configuration, and meta-packages using Recommends instead of Depends/Meta-Depends, would render them pretty useless. There are good reasons for it to be configurable: - it's useful for debugging purposes In what ways? But this is getting OT now :) - in cases of specific packages, disabling recommends-by-default and then hand-selecting the ones you want may be more efficient than installing all recommends and selecting those to remove afterwards This should be on a per-package basis, don't you believe? # apt-get --no-install-recommends install metapackage But then again, I don't see a point here either. What's the use of a metapackage if you only choose 2-3 from, say, 20-30 dependencies? You'd better go with selecting those 2-3 directly. At least IMHO :) Try to change your POV from the uber-user, who knows how to install base packages and let others be pulled in, to the low-level users, which want gnome installed, but don't want rhythmbox nor banshee installed. This is what they do (writing the CLI version, but they're likely to use something like Synaptic): # aptitude install gnome # aptitude remove rhythmbox OOPS! Since aptitude does autoremove by default, the users suddenly get asked to remove all their desktop environments. How many requests of this type have you seen on IRC, mailing lists, Usenet? I've seen *TOO MANY*, and that's why I drafted this DEP in the first place. Definitely no, I don't think this is a marginal situation not worth doing some implementation work. (and I could help making patches, where I can) - it's how we want buildds and developer build chroots to be configured, so that build-dependencies aren't overlooked because they're usually installed as recommends Uh? Could you explain a bit more? But that doesn't mean it makes sense for users to set this setting globally on their systems, or to design further complexity into our package manager to accomodate such configurations. How would this be any complex? I mean, maybe handling a blacklist might be, but we're already having the auto-installed vs. manually-installed lists, so adding a new one shouldn't be too hard. Also, since Meta-Depends would act as Recommends, with the only difference that it's not configurable, I can't see any complexity in changing the code from (pseudo-code): if field == Recommends: # do something, and handle APT::Install-Recommends to: if field in [Recommends, Meta-Depends]: # do something if field == Recommends: # handle APT::Install-Recommends ? This might be a bit simplistic, I agree, but I hope this clears my point. the vast majority of metapackage dependencies are moved from Depends to Recommends, so you can remove those Recommends manually without forcing removal of the metapackage; This already happens now, or did I miss something? The difference is that the packages that are now listed as Depends would be moved to Recommends. And they could be not installed at all, depending on the user's configuration, which we do not want to happen. Kindly, David -- . ''`. Debian developer |
Re: [RFC] DEP-6: Meta-Package debian/control field
David Paleino, 2009-12-21 09:13:17 +0100 : [...] I mean, meta-packages should *always* have their Recommends installed, otherwise they have no point in existing. If it's *always*, then… isn't your proposal pointless? If it's merely a *should*, then Recommends is a fine solution. [...] What's the use of a metapackage if you only choose 2-3 from, say, 20-30 dependencies? You'd better go with selecting those 2-3 directly. At least IMHO :) And that's what we have tasks for. Try to change your POV from the uber-user, who knows how to install base packages and let others be pulled in, to the low-level users, which want gnome installed, but don't want rhythmbox nor banshee installed. This is what they do (writing the CLI version, but they're likely to use something like Synaptic): # aptitude install gnome # aptitude remove rhythmbox OOPS! Since aptitude does autoremove by default, the users suddenly get asked to remove all their desktop environments. How many requests of this type have you seen on IRC, mailing lists, Usenet? I've seen *TOO MANY*, and that's why I drafted this DEP in the first place. Definitely no, I don't think this is a marginal situation not worth doing some implementation work. (and I could help making patches, where I can) Then I suggest you just help converting the gnome metapackage to a task, since this'll work with no intrusive changes in our tools. Roland. -- Roland Mas Neko-no me-to, onna-gokoro-to, aki-no-sora. -- Proverbe japonais (« Souvent femme varie, bien fol est qui s'y fie. ») -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [RFC] DEP-6: Meta-Package debian/control field
Roland Mas wrote: David Paleino, 2009-12-21 09:13:17 +0100 : [...] I mean, meta-packages should *always* have their Recommends installed, otherwise they have no point in existing. If it's *always*, then… isn't your proposal pointless? If it's merely a *should*, then Recommends is a fine solution. No, I probably misworded my intention there. A meta-package should always have their Recommends/Depends/whatever installed, and shouldn't get uninstalled when one of these gets removed (either, this removed one should be blacklisted someway) [...] What's the use of a metapackage if you only choose 2-3 from, say, 20-30 dependencies? You'd better go with selecting those 2-3 directly. At least IMHO :) And that's what we have tasks for. Tasks aren't for this, I suppose. [..] Then I suggest you just help converting the gnome metapackage to a task, since this'll work with no intrusive changes in our tools. So you're suggesting me to also do a wicd task. In experimental I have wicd depending on wicd-daemon + wicd-curses|wicd- gtk -- (it's a simple case, where the user might manually choose the components, but it's good for the sake of exampling). A user having wicd installed now, and upgrading to experimental, might want to remove one of the components: # apt-get --purge remove wicd-curses This will also uninstall wicd, and mark wicd-daemon and wicd-gtk for autoremoval. I don't think we should escalate metapackages to tasks, sorry. -- . ''`. Debian developer | http://wiki.debian.org/DavidPaleino : :' : Linuxer #334216 --|-- http://www.hanskalabs.net/ `. `'` GPG: 1392B174 | http://snipr.com/qa_page `- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [RFC] DEP-6: Meta-Package debian/control field
David Paleino wrote: [..] So you're suggesting me to also do a wicd task. In experimental I have wicd depending on wicd-daemon + wicd-curses|wicd- gtk -- (it's a simple case, where the user might manually choose the components, but it's good for the sake of exampling). As explained on IRC, I might have pushed the example a bit had here, but I suppose from a pkg manager POV it's the same. David -- . ''`. Debian developer | http://wiki.debian.org/DavidPaleino : :' : Linuxer #334216 --|-- http://www.hanskalabs.net/ `. `'` GPG: 1392B174 | http://snipr.com/qa_page `- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [RFC] DEP-6: Meta-Package debian/control field
Steve Langasek wrote: In this scenario, with Recommends installed by default (the only sane model), the vast majority of metapackage dependencies are moved from Depends to Recommends, so you can remove those Recommends manually without forcing removal of the metapackage; and you can remove the metapackage without causing cascading autoremoval of e.g., half your desktop. If I may, the Recommends installed by default scenario doesn't really apply here, as the goal here is to remove some dependencies that you don't want to have, because you want a smaller system. So what you are asking for is having even MORE packages installed when we want LESS. Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [RFC] DEP-6: Meta-Package debian/control field
Steve Langasek wrote: From what I can tell, the only difference between the two implementations is compatibility with disabling installation of Recommends by default. I don't think this is a good rationale for adding yet another package relationship field. The Recommends field is *already* defined in Policy to have the behavior you're looking for (installed by default but not a hard requirement), and I don't see any reason that metapackages should need the added complexity of a different field. Without this metapackage thing, the only option we have is to have so many many metapackages, so we can choose one of them. This is not very nice, because that means that maintainers have to have the will to do it (which wont ever be the case for all of them). Which is why a real system to manage this would be nice. Another point would be that a meta-package could add a new meta-dependency in a new release. Try to change your POV from the uber-user, who knows how to install base packages and let others be pulled in, to the low-level users, which want gnome installed, but don't want rhythmbox nor banshee installed. This is what they do (writing the CLI version, but they're likely to use something like Synaptic): # aptitude install gnome # aptitude remove rhythmbox OOPS! Since aptitude does autoremove by default, the users suddenly get asked to remove all their desktop environments. How many requests of this type have you seen on IRC, mailing lists, Usenet? I've seen *TOO MANY*, and that's why I drafted this DEP in the first place. EXACTLY! This is not only because of requests, this has annoyed everyone for a long long time. Then I suggest you just help converting the gnome metapackage to a task, since this'll work with no intrusive changes in our tools. Well, the issue is not ONLY with gnome, there are many many more. For example the X system installing all drivers, then you want to remove few of them that you don't care and identify as not for you, but keep all the rest of just in case. I see few other examples in packages that I maintain myself where removing 1 or 2 package could be nice, still keeping new packages that would come with the metapackage in case of an upgrade, and giving freedom to users to do what they want. Andreas Metzler wrote: The current proposal is not backwards compatible since it fundamentally changes the meaning of Depends. Depends is transitive. If A depends on B, and B depends on C. A can rely on functionality proveided by C. Your proposal breaks that, since it allows removal of C (assuming B is a meta package), keeping it installed in a broken state. I am not convinced that the gain (easily install KDE without kmail, or something like that) is worth this price. It changes a clear relation to something that most of the times works as expected, except for some special cases. I do agree that the proposed implementation is bad, and that Depends should not change meaning. I do like more the Meta-Depends: instead of Depends: if we want to keep the original idea. How about having a differentiation about the idea and the implementation in this discussion? :P Also, I think having a Metapackage: yes field IS a good idea anyway, even if there's absolutely NOTHING ELSE implemented with it but search functionalities, which would be very convenient (unless there's also Meta-Depends, but we could imagine a package that would like the functionality of Meta-Depends and still not being a Meta-Package and installing useful files...). Does the majority agree with me on that point here? Just my 2 cents, as I wont be the one implementing anything... :) Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [RFC] DEP-6: Meta-Package debian/control field
On Mon, Dec 21, 2009 at 09:40:37AM +0100, David Paleino wrote: So you're suggesting me to also do a wicd task. In experimental I have wicd depending on wicd-daemon + wicd-curses|wicd- gtk -- (it's a simple case, where the user might manually choose the components, but it's good for the sake of exampling). A user having wicd installed now, and upgrading to experimental, might want to remove one of the components: # apt-get --purge remove wicd-curses This will also uninstall wicd, and mark wicd-daemon and wicd-gtk for autoremoval. I don't think we should escalate metapackages to tasks, sorry. Special autoremoval handling of metapackages addresses this, without meddling with the existing package relationship fields. This could be done with special handling of 'Section: metapackages', or by adding a new 'Metapackage: yes' field (as I think some would prefer based on comments on IRC). Package: wicd Section: metapackage Depends: wicd-curses|wicd-gtk, wicd-daemon # apt-get purge wicd-curses Reading package lists... Done Building dependency tree Reading state information... Done The following packages will be REMOVED: wicd-curses* wicd* 0 upgraded, 0 newly installed, 2 to remove and 2 not upgraded. After this operation, 57.3kB disk space will be freed. Do you want to continue [Y/n]? Those are exactly the correct semantics. It makes no sense to remove the depends of a metapackage *and leave the metapackage installed* - what purpose would that serve? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: [RFC] DEP-6: Meta-Package debian/control field
Steve Langasek wrote: Those are exactly the correct semantics. It makes no sense to remove the depends of a metapackage *and leave the metapackage installed* - what purpose would that serve? Being able to # apt-get --purge remove wicd (thus removing any dependency/recommends/anything), without caring for the removed parts singularly? However, seems like on IRC we reached kind of a consensus on the fact that metapackages should use Recommends instead of Depends. I plan to do a mass- bug filing on this issue sooner or later, just need some time to do it :) I might change this DEP to propose a new field, halfway betwen Recommends and Depends (as weasel suggested, Weak-Depends), but haven't carefully thought at it yet. David -- . ''`. Debian developer | http://wiki.debian.org/DavidPaleino : :' : Linuxer #334216 --|-- http://www.hanskalabs.net/ `. `'` GPG: 1392B174 | http://snipr.com/qa_page `- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [RFC] DEP-6: Meta-Package debian/control field
On Mon, 2009-12-21 at 07:52 -0800, Steve Langasek wrote: On Mon, Dec 21, 2009 at 09:40:37AM +0100, David Paleino wrote: So you're suggesting me to also do a wicd task. In experimental I have wicd depending on wicd-daemon + wicd-curses|wicd- gtk -- (it's a simple case, where the user might manually choose the components, but it's good for the sake of exampling). A user having wicd installed now, and upgrading to experimental, might want to remove one of the components: # apt-get --purge remove wicd-curses This will also uninstall wicd, and mark wicd-daemon and wicd-gtk for autoremoval. I don't think we should escalate metapackages to tasks, sorry. Special autoremoval handling of metapackages addresses this, without meddling with the existing package relationship fields. This could be done with special handling of 'Section: metapackages', or by adding a new 'Metapackage: yes' field (as I think some would prefer based on comments on IRC). Package: wicd Section: metapackage Depends: wicd-curses|wicd-gtk, wicd-daemon # apt-get purge wicd-curses Reading package lists... Done Building dependency tree Reading state information... Done The following packages will be REMOVED: wicd-curses* wicd* 0 upgraded, 0 newly installed, 2 to remove and 2 not upgraded. After this operation, 57.3kB disk space will be freed. Do you want to continue [Y/n]? Those are exactly the correct semantics. It makes no sense to remove the depends of a metapackage *and leave the metapackage installed* - what purpose would that serve? In this particular case, none. But in the general case there are reasons to keep the metapackage installed. For example, I want to try out gnome. So I install the gnome metapackage. I do not want (say) brasero. But I still want everything removable by just saying aptitude remove gnome. -- Saludos, Felipe Sateler -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [RFC] DEP-6: Meta-Package debian/control field
On Mon, Dec 21, 2009 at 05:00:35PM +0100, David Paleino wrote: However, seems like on IRC we reached kind of a consensus on the fact that metapackages should use Recommends instead of Depends. I plan to do a mass- bug filing on this issue sooner or later, just need some time to do it :) What sense does that have? apt-get install openoffice.org installing nothing? (Assuming a system has a senseful configuration and has the recommends-install thing removed? Ok, OOo is a bad example, let's get a better one: mysql-server or postgresql. On (minimal as you can get) servers you don't want to install recommends, and this would break those, too. (Yes, they are metapackages) Grüße/Regards, Rene -- .''`. René Engelhard -- Debian GNU/Linux Developer : :' : http://www.debian.org | http://people.debian.org/~rene/ `. `' r...@debian.org | GnuPG-Key ID: D03E3E70 `- Fingerprint: E12D EA46 7506 70CF A960 801D 0AA0 4571 D03E 3E70 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [RFC] DEP-6: Meta-Package debian/control field
Rene Engelhard wrote: On Mon, Dec 21, 2009 at 05:00:35PM +0100, David Paleino wrote: However, seems like on IRC we reached kind of a consensus on the fact that metapackages should use Recommends instead of Depends. I plan to do a mass- bug filing on this issue sooner or later, just need some time to do it :) What sense does that have? apt-get install openoffice.org installing nothing? (Assuming a system has a senseful configuration and has the recommends-install thing removed? Ok, OOo is a bad example, let's get a better one: mysql-server or postgresql. On (minimal as you can get) servers you don't want to install recommends, and this would break those, too. (Yes, they are metapackages) Go tell this to people on IRC ;) They've been saying that my auto-recommends off, but I want working metapackages configuration is insane! :P That's why I wanted to propose a Meta-Depends (or whatever we call that), that must only be used by metapackages, and works like Recommends, but is not configurable. David -- . ''`. Debian developer | http://wiki.debian.org/DavidPaleino : :' : Linuxer #334216 --|-- http://www.hanskalabs.net/ `. `'` GPG: 1392B174 | http://snipr.com/qa_page `- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [RFC] DEP-6: Meta-Package debian/control field
On 2009-12-21, Rene Engelhard r...@debian.org wrote: Assuming a system has a senseful configuration and has the recommends-install thing removed? I am not really sure that you could use this to back up your claims, really. This declares a strong, but not absolute, dependency. The Recommends field should list packages that would be found together with this one in all but unusual installations. You're on your own with these. Kind regards, Philipp Kern -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [RFC] DEP-6: Meta-Package debian/control field
Rene Engelhard writes: On Mon, Dec 21, 2009 at 05:00:35PM +0100, David Paleino wrote: However, seems like on IRC we reached kind of a consensus on the fact that metapackages should use Recommends instead of Depends. I plan to do a mass- bug filing on this issue sooner or later, just need some time to do it :) What sense does that have? apt-get install openoffice.org installing nothing? (Assuming a system has a senseful configuration and has the recommends-install thing removed? Ok, OOo is a bad example, let's get a better one: mysql-server or postgresql. On (minimal as you can get) servers you don't want to install recommends, and this would break those, too. (Yes, they are metapackages) Given the fact that there is no clear definition what a metapackage is (yes, we all think we know what it is), the opposite is also true: openoffice.org, mysql- server, postgresql could equally be thought of not being metapackages and their Depends are not to be demoted to Recommends. It all boils down to the maintainer decision what to put in Depends and Recommends, regardless of whether they thought of their package as being a metapackage or not. -- pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [RFC] DEP-6: Meta-Package debian/control field
On Mon, Dec 21, 2009 at 05:00:35PM +0100, David Paleino wrote: Those are exactly the correct semantics. It makes no sense to remove the depends of a metapackage *and leave the metapackage installed* - what purpose would that serve? Being able to # apt-get --purge remove wicd (thus removing any dependency/recommends/anything), without caring for the removed parts singularly? That result can be achieved by *not* making wicd a metapackage, and moving its Depends to Recommends. So removing wicd-curses will not remove wicd automatically, but removing wicd will remove wicd-* automatically. Or do you really mean that you expect the package manager to treat removal of 'wicd' differently based on whether the removal is triggered by 'apt-get remove wicd' vs. 'apt-get remove dependency-of-wicd'? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: [RFC] DEP-6: Meta-Package debian/control field
Steve Langasek wrote: Or do you really mean that you expect the package manager to treat removal of 'wicd' differently based on whether the removal is triggered by 'apt-get remove wicd' vs. 'apt-get remove dependency-of-wicd'? Exactly that, plus the fact that it is a metapackage. -- . ''`. Debian developer | http://wiki.debian.org/DavidPaleino : :' : Linuxer #334216 --|-- http://www.hanskalabs.net/ `. `'` GPG: 1392B174 | http://snipr.com/qa_page `- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [RFC] DEP-6: Meta-Package debian/control field
David Paleino writes: Rene Engelhard wrote: On Mon, Dec 21, 2009 at 05:00:35PM +0100, David Paleino wrote: However, seems like on IRC we reached kind of a consensus on the fact that metapackages should use Recommends instead of Depends. I plan to do a mass- bug filing on this issue sooner or later, just need some time to do it :) What sense does that have? apt-get install openoffice.org installing nothing? (Assuming a system has a senseful configuration and has the recommends-install thing removed? Ok, OOo is a bad example, let's get a better one: mysql-server or postgresql. On (minimal as you can get) servers you don't want to install recommends, and this would break those, too. (Yes, they are metapackages) Go tell this to people on IRC ;) They've been saying that my auto-recommends off, but I want working metapackages configuration is insane! :P There is a big difference between being insane and being on your own, really. That's why I wanted to propose a Meta-Depends (or whatever we call that), that must only be used by metapackages, and works like Recommends, but is not configurable. Unfortunately, that Meta-Depends introduces new package relationship, while we already have three of them (absolute, strong, weak). Next, if you are going to register metapackages with the packaging system (which basically means yet another dedicated field or a dedicated section resp., I'm not arguing which is better) you should firstly propose a sensible and clear definition what a metapackage is, so it is clear when maintainers are supposed to use that metapackage field or section. That would eventually answer the question whether or not so defined metapackages must be treated specially on autoremove Co. I'm sorry I can't come with a complete solution, which is not that easy, but this is just my view how to start sorting out the mess. -- pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [RFC] DEP-6: Meta-Package debian/control field
Thomas Goirand wrote: Steve Langasek wrote: In this scenario, with Recommends installed by default (the only sane model), the vast majority of metapackage dependencies are moved from Depends to Recommends, so you can remove those Recommends manually without forcing removal of the metapackage; and you can remove the metapackage without causing cascading autoremoval of e.g., half your desktop. If I may, the Recommends installed by default scenario doesn't really apply here, as the goal here is to remove some dependencies that you don't want to have, because you want a smaller system. So what you are asking for is having even MORE packages installed when we want LESS. No, he's not asking for anything because Recommends are already installed by default. So by using Recommends instead of Depends in metapackages, you're able to remove any package you don't like or want, resulting in less packages, not more. Emilio -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [RFC] DEP-6: Meta-Package debian/control field
Felipe Sateler a écrit : In this particular case, none. But in the general case there are reasons to keep the metapackage installed. For example, I want to try out gnome. So I install the gnome metapackage. I do not want (say) brasero. But I still want everything removable by just saying aptitude remove gnome. Just wait until somebody implements somepackagemanager dummy brasero that would pull brasero, use equivs (or some other internal system) to build a brasero equivalent (but without any files), remove brasero and install it instead, put it in a special list, and do that everytime brasero (real package) is meant to be installed. *That* would be reasonable, and would not interfere with what the packagers do. And you could get somepackagemanager undummy brasero and somepackagemanager dummylist, which would be a must. -- Jean-Christophe Dubacq -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [RFC] DEP-6: Meta-Package debian/control field
David Paleino wrote: Hello people, per the DEP process described at http://dep.debian.net/deps/dep0/, this is the first call for comments on this proposal. Title: Meta-Package debian/control field DEP: 6 [..] Here's the full text, for your convenience: Introduction This document proposes a new field for debian/control, to be used in the so-called meta-packages. A meta-package is a package which does not contain any files to be installed. Instead it has dependencies to other packages. There are several uses for metapackages, for example to provide a Desktop Environment with some default applications installed. Rationale - With the *autoremove* command being now widely used, it can become difficult for a user to install a meta-package but some packages it depends on. In fact, when removing any dependency of the meta-package, it gets removed as well, and all other dependencies become *leaf packages* that autoremove will try to remove from the system. This is usually not what the users want, as they probably installed (or had it by default) the meta-package to have a standard environment, but don't want or need specific packages. With the current situation, the only solution is to specify as *manually installed* the packages the users want to keep on their systems. This document thus tries to introduce a new mechanism for meta-packages, which would be marked with **Meta-Package: yes** in the debian/control control file, and whose dependencies removal would not cause the dependant removal. Think of this as a new Recommends field, which cannot be controlled via /etc/apt/preferences (or similar configuration file). Backwards Compatibility --- We started thinking about Meta-Depends fields, but soon abandoned the idea. This is because this field would break existing package managers which haven't implemented yet this DEP. That's why we chose to keep Depends, and add an extra field, called **Meta-Package**. Implementation -- ### Packages ### Meta-packages should use **Meta-Package: yes** in a binary stanza in the *debian/control* file. ### Package managers ### Package managers, upon removal of any package, should check dependant packages, and act accordingly. If any dependant package is a meta-package, as defined by this document, it should **NOT** be removed, opposed to what the current implementations do. The package manager should then add the removed package to a blacklist for the dependant meta-package. This allows for upgrades of the meta-package without re-installing everything again, i.e. the package manager should check the dependencies of the meta-package against its blacklist, if present. If the Meta-Package field is not present, then the package manager should act normally, without any modification from the current behaviour. If the meta-package is removed, all its dependencies are marked for auto-removal, following the current behaviour. Blacklist management Package managers should allow for deletion of the blacklist upon removal of the meta-package. Moreover, they should allow the deletion of the blacklist, and the installation of the missing meta-package dependencies at the same time. Tools support - ### apt-get ### None. ### aptitude ### None. ### cupt ### None. ### smart ### None. Changes --- * 2009-12-20: [ dapal ] * First draft, RFC made on debian-devel -- . ''`. Debian developer | http://wiki.debian.org/DavidPaleino : :' : Linuxer #334216 --|-- http://www.hanskalabs.net/ `. `'` GPG: 1392B174 | http://snipr.com/qa_page `- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [RFC] DEP-6: Meta-Package debian/control field
Hello, David Paleino wrote: Implementation [...] ### Package managers ### [...] If any dependant package is a meta-package, as defined by this document, it should **NOT** be removed, opposed to what the current implementations do. The package manager should then add the removed package to a blacklist for the dependant meta-package. This allows for upgrades of the meta-package without re-installing everything again, i.e. the package manager should check the dependencies of the meta-package against its blacklist, if present. No, it doesn't. Dpkg and any sane high-level package manager won't consider installing/upgrading/keeping some package (meta or not) without all Depends installed. What you described above seems more like 'Recommends'-handling to me, and some high-level package managers (I can say for cupt) have some logic to not install the same recommended packages again if they were not installed or removed when upgrading parent packages. Blacklist management Package managers should allow for deletion of the blacklist upon removal of the meta-package. Moreover, they should allow the deletion of the blacklist, and the installation of the missing meta-package dependencies at the same time. The blacklist support also is already present somewhere (speaking of cupt, you can set pin like -2000 to some package, and it won't be pulled for Recommends/Suggests). To summarize: if I am not mistaken, this DEP cannot be implemented due to technical reasons in its current form. -- Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com C++/Perl developer, Debian Developer signature.asc Description: OpenPGP digital signature
Re: [RFC] DEP-6: Meta-Package debian/control field
Eugene V. Lyubimkin wrote: Hello, Hello Eugene, thanks for your feedback. David Paleino wrote: Implementation [...] ### Package managers ### [...] If any dependant package is a meta-package, as defined by this document, it should **NOT** be removed, opposed to what the current implementations do. The package manager should then add the removed package to a blacklist for the dependant meta-package. This allows for upgrades of the meta-package without re-installing everything again, i.e. the package manager should check the dependencies of the meta-package against its blacklist, if present. No, it doesn't. Dpkg and any sane high-level package manager won't consider installing/upgrading/keeping some package (meta or not) without all Depends installed. We can always change our tools to comply with that, no? :) What you described above seems more like 'Recommends'-handling to me, and some high-level package managers (I can say for cupt) have some logic to not install the same recommended packages again if they were not installed or removed when upgrading parent packages. Yes, it's a concept similar to Recommends, the only difference is that you cannot override their installation (while, at the current state, you CAN say not to install Recommends). Blacklist management Package managers should allow for deletion of the blacklist upon removal of the meta-package. Moreover, they should allow the deletion of the blacklist, and the installation of the missing meta-package dependencies at the same time. The blacklist support also is already present somewhere (speaking of cupt, you can set pin like -2000 to some package, and it won't be pulled for Recommends/Suggests). Ok, I was thinking at something more automated, to be honest. See this example: # apt-get install metapackage # apt-get --purge remove dependency1 At this point, dependency1 gets blacklisted or -- if you prefer -- the package manager sets is pin to -infinity. # apt-get clean-blaclist metapackage The blacklist for metapackage gets cleaned, and, at the same time, a apt- get --reinstall install metapackage is issued. (sorry for using apt-get and not cupt for my examples ;)) To summarize: if I am not mistaken, this DEP cannot be implemented due to technical reasons in its current form. Could you please expand this a bit? Adding a new field to debian/control always needs a change in our tools, and this one touches package managers. What's wrong with this? :) Thanks for commenting, David -- . ''`. Debian developer | http://wiki.debian.org/DavidPaleino : :' : Linuxer #334216 --|-- http://www.hanskalabs.net/ `. `'` GPG: 1392B174 | http://snipr.com/qa_page `- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [RFC] DEP-6: Meta-Package debian/control field
David Paleino da...@debian.org wrote: [...] With the *autoremove* command being now widely used, it can become difficult for a user to install a meta-package but some packages it depends on. I do not understand this, is there a word missing? [...] This document thus tries to introduce a new mechanism for meta-packages, which would be marked with **Meta-Package: yes** in the debian/control control file, and whose dependencies removal would not cause the dependant removal. Think of this as a new Recommends field, [...] Backwards Compatibility --- We started thinking about Meta-Depends fields, but soon abandoned the idea. This is because this field would break existing package managers which haven't implemented yet this DEP. That's why we chose to keep Depends, and add an extra field, called **Meta-Package**. [...] The current proposal is not backwards compatible since it fundamentally changes the meaning of Depends. Depends is transitive. If A depends on B, and B depends on C. A can rely on functionality proveided by C. Your proposal breaks that, since it allows removal of C (assuming B is a meta package), keeping it installed in a broken state. I am not convinced that the gain (easily install KDE without kmail, or something like that) is worth this price. It changes a clear relation to something that most of the times works as expected, except for some special cases. cu andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure' -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [RFC] DEP-6: Meta-Package debian/control field
David Paleino wrote: Eugene V. Lyubimkin wrote: No, it doesn't. Dpkg and any sane high-level package manager won't consider installing/upgrading/keeping some package (meta or not) without all Depends installed. We can always change our tools to comply with that, no? :) Well, yes, but I don't think that modifying low-level package manager is justified for high-level package manager issues, and I suspect dpkg developers will agree with me in this question. # apt-get install metapackage # apt-get --purge remove dependency1 At this point, dependency1 gets blacklisted or -- if you prefer -- the package manager sets is pin to -infinity. # apt-get clean-blaclist metapackage The blacklist for metapackage gets cleaned, and, at the same time, a apt- get --reinstall install metapackage is issued. I see some benefits for this approach, but IMHO it's a bit over-engineered - one will need to generate several new commands (view blacklist, view list of blacklists, already mentioned clean/change-blacklist, maybe something else), plus it adds even more complexity to already complex problem resolver subsystem - not I would want to implement, personally. To summarize: if I am not mistaken, this DEP cannot be implemented due to technical reasons in its current form. Could you please expand this a bit? Adding a new field to debian/control always needs a change in our tools and this one touches package managers. What's wrong with this? :) This one needs changes in dpkg. While, for example, fiddling with Recommends may require some changes only from high-level package managers. To rephrase, I don't see any future for this DEP before you get dpkg developers approval for special-handling for meta-packages. -- Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com C++/Perl developer, Debian Developer signature.asc Description: OpenPGP digital signature
Re: [RFC] DEP-6: Meta-Package debian/control field
Eugene V. Lyubimkin writes: Hello, David Paleino wrote: Implementation [...] ### Package managers ### [...] If any dependant package is a meta-package, as defined by this document, it should **NOT** be removed, opposed to what the current implementations do. The package manager should then add the removed package to a blacklist for the dependant meta-package. This allows for upgrades of the meta-package without re-installing everything again, i.e. the package manager should check the dependencies of the meta-package against its blacklist, if present. No, it doesn't. Dpkg and any sane high-level package manager won't consider installing/upgrading/keeping some package (meta or not) without all Depends installed. I agree. That flies directly in the face of Policy definition of Depends: cite This declares an absolute dependency. A package will not be configured unless all of the packages listed in its Depends field have been correctly configured. /cite Degrading such a base and well established feature looks like a criminal act, at best ;-) What you described above seems more like 'Recommends'-handling to me, and some high-level package managers (I can say for cupt) have some logic to not install the same recommended packages again if they were not installed or removed when upgrading parent packages. Blacklist management Package managers should allow for deletion of the blacklist upon removal of the meta-package. Moreover, they should allow the deletion of the blacklist, and the installation of the missing meta-package dependencies at the same time. The blacklist support also is already present somewhere (speaking of cupt, you can set pin like -2000 to some package, and it won't be pulled for Recommends/Suggests). To summarize: if I am not mistaken, this DEP cannot be implemented due to technical reasons in its current form. Yes, this could be corrected. Moreover, I imagine that having metapackages clearly identified via boolean Meta-Package field, would help searching based on a dedicated field, since currently the only way I'm currently aware of to identify all metapackages is by matching Description field (apt-cache search ^metapackage) which is not even remotely reliable of course. Of course new fields shouldn't be added lightly, and I can imagine people opposing that as well. -- pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [RFC] DEP-6: Meta-Package debian/control field
Andreas Metzler wrote: David Paleino da...@debian.org wrote: [...] With the *autoremove* command being now widely used, it can become difficult for a user to install a meta-package but some packages it depends on. I do not understand this, is there a word missing? Probably I didn't use a clear wording. [..] to install a meta-package except for some packages it depends on. Is that clearer? Backwards Compatibility --- We started thinking about Meta-Depends fields, but soon abandoned the idea. This is because this field would break existing package managers which haven't implemented yet this DEP. That's why we chose to keep Depends, and add an extra field, called **Meta-Package**. [...] The current proposal is not backwards compatible since it fundamentally changes the meaning of Depends. Depends is transitive. If A depends on B, and B depends on C. A can rely on functionality proveided by C. Your proposal breaks that, since it allows removal of C (assuming B is a meta package), keeping it installed in a broken state. I hope no-one ever depends on a meta-package. Do you have any real case for this? I am not convinced that the gain (easily install KDE without kmail, or something like that) Yes, that's exactly the point. is worth this price. It changes a clear relation to something that most of the times works as expected, except for some special cases. Special cases like depending on a meta-package? I'd personally change policy to forbid that ;) Thanks for commenting, David -- . ''`. Debian developer | http://wiki.debian.org/DavidPaleino : :' : Linuxer #334216 --|-- http://www.hanskalabs.net/ `. `'` GPG: 1392B174 | http://snipr.com/qa_page `- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [RFC] DEP-6: Meta-Package debian/control field
George Danchev wrote: Eugene V. Lyubimkin writes: No, it doesn't. Dpkg and any sane high-level package manager won't consider installing/upgrading/keeping some package (meta or not) without all Depends installed. I agree. That flies directly in the face of Policy definition of Depends: Come on people, Policy can be changed :) cite This declares an absolute dependency. A package will not be configured unless all of the packages listed in its Depends field have been correctly configured. /cite Degrading such a base and well established feature looks like a criminal act, at best ;-) What if we added apart from metapackages, identified by Meta-Package: yes? I'm not yet seeing any strong argument against this DEP, but I'm clearly biased ;) David -- . ''`. Debian developer | http://wiki.debian.org/DavidPaleino : :' : Linuxer #334216 --|-- http://www.hanskalabs.net/ `. `'` GPG: 1392B174 | http://snipr.com/qa_page `- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [RFC] DEP-6: Meta-Package debian/control field
David Paleino da...@debian.org wrote: Andreas Metzler wrote: [...] I hope no-one ever depends on a meta-package. Do you have any real case for this? [...] kde depends on kde-core. cu andreas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [RFC] DEP-6: Meta-Package debian/control field
Andreas Metzler wrote:
David Paleino da...@debian.org wrote:
Andreas Metzler wrote:
[...]
I hope no-one ever depends on a meta-package.
Do you have any real case for this?
[...]
kde depends on kde-core.
And both are metapackages.
(apart from the fact that I can't find kde nor kde-core, but I'm basing my
example on kde-full depending on kde-minimal, which should be the same thing
AFAIU)
Currently, kde-minimal throws in kdebase-{runtime,workspace,apps}. Each of
these throws in other things. Let's look at, say, kdebase-workspace. It
depends on non-essential things, which become essential per the Depends:
mechanism.
With this DEP implemented, and both kde-full and kde-minimal Meta:yes, you
could:
# apt-get install kde-full
# apt-get --purge remove kdebase-workspace
and still have a working system.
You could also remove kdebase-runtime and, unless there's some other package
depending on it, you still have a working system.
Moreover, kde-full depending on kde-minimal is not a good example, at all.
It's one metapackage depending on another -- what you probably wanted to
highlight is the case where some normal package depends on a meta one.
In this case, I'd say that it's a bug, even though I agree it's a subtle
one.
The meta-package can change its dependencies whenever the maintainer wants,
and one should really depend on direct packages, instead of what gets pulled
in by the package manager.
This is the same reasoning as specifying each needed build-dependency in a
package, and not relying on the dependency chain.
Hope this clears it a bit, and addresses your concerns :)
Kindly,
David
--
. ''`. Debian developer | http://wiki.debian.org/DavidPaleino
: :' : Linuxer #334216 --|-- http://www.hanskalabs.net/
`. `'` GPG: 1392B174 | http://snipr.com/qa_page
`- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [RFC] DEP-6: Meta-Package debian/control field
I agree with Eugene: the spec as presented is flawed. All package management tools (you forgot to list dpkg) treat Depends-satisfaction as an invariant, and there isn't really a compelling reason for this to change. The wording you present is a little confusing, but once you work through it, it's clear that it says treat Depends on this package like Recommends. Except that there may be an unless you don't tagged on. I actually would prefer a Meta-Depends sort of solution. The dependencies we're talking about are really not package dependencies in the normal sense at all, and we shouldn't be confusing them with normal dependencies. IMO, that basic conflation, while a convenient and expedient hack when it was introduced years ago, is the cause of our troubles. Arguably, your Meta-Package proposal really says change all Depends to Meta-Depends if Meta-Package is true. However, I don't like making the meaning of Depends dependent (hah) on another package field, or overloading the meaning of such a basic part of the package system. For instance, dpkg shouldn't care about metapackages at all (IMO), any more than it cares about Recommends; this is a high-level concept that doesn't have to do with guaranteed relationships among installed packages. I also don't like the definition of Meta-Depends as like Depends, except foo; I think that the behavior and intention of Meta-Depends are different enough that they should be described explicitly. To summarize: if we're going to introduce a new package relationship, I'd like to see us do it right and up-front rather than on the cheap with a hack we'll have to live with for years. (I apologize for not including my own proposal in this mail, due to it suffering from an acute case of non-existence; if I have time I will write one, but please don't count on that what with holidays and real life and all) Cheers, Daniel -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [RFC] DEP-6: Meta-Package debian/control field
Daniel Burrows wrote: [..] I actually would prefer a Meta-Depends sort of solution. The dependencies we're talking about are really not package dependencies in the normal sense at all, and we shouldn't be confusing them with normal dependencies. IMO, that basic conflation, while a convenient and expedient hack when it was introduced years ago, is the cause of our troubles. Well, we (me and Luca Bruno (not kaeso, the other one)) decided not to use Meta-Depends because that would've broken meta-packages installed with $non_compliant_tool . Other than this, we could carefully plan this change, so that we're sure that before any metapackage uses this field, the Policy get changed and all current tools support it. Kindly, David -- . ''`. Debian developer | http://wiki.debian.org/DavidPaleino : :' : Linuxer #334216 --|-- http://www.hanskalabs.net/ `. `'` GPG: 1392B174 | http://snipr.com/qa_page `- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [RFC] DEP-6: Meta-Package debian/control field
On Sun, Dec 20, 2009 at 05:06:39PM +0100, David Paleino wrote: In fact, when removing any dependency of the meta-package, it gets removed as well, and all other dependencies become *leaf packages* that autoremove will try to remove from the system. This is usually not what the users want, as they probably installed (or had it by default) the meta-package to have a standard environment, but don't want or need specific packages. Have you looked at the prior art in this area in Ubuntu? Ubuntu defines a special archive section, 'metapackages', which results in special tagging/handling of the Depends and Recommends of the package so that they're not autoremoved if the metapackage is removed. This is implemented in the high-level package management tools. In this scenario, with Recommends installed by default (the only sane model), the vast majority of metapackage dependencies are moved from Depends to Recommends, so you can remove those Recommends manually without forcing removal of the metapackage; and you can remove the metapackage without causing cascading autoremoval of e.g., half your desktop. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: [RFC] DEP-6: Meta-Package debian/control field
Steve Langasek wrote: On Sun, Dec 20, 2009 at 05:06:39PM +0100, David Paleino wrote: In fact, when removing any dependency of the meta-package, it gets removed as well, and all other dependencies become *leaf packages* that autoremove will try to remove from the system. This is usually not what the users want, as they probably installed (or had it by default) the meta-package to have a standard environment, but don't want or need specific packages. Have you looked at the prior art in this area in Ubuntu? Nope, sorry, didn't even know Ubuntu treated metapackages in a special way. Ubuntu defines a special archive section, 'metapackages', which results in special tagging/handling of the Depends and Recommends of the package so that they're not autoremoved if the metapackage is removed. This is implemented in the high-level package management tools. Well, our proposal prospects something different: the metapackage is not removed (thus everything else is not autoremoved) if one of its Meta- Depends/Depends is removed. In this scenario, with Recommends installed by default (the only sane model), On my host, Recommends are not installed by default, and this is configurable. A similar configuration, and meta-packages using Recommends instead of Depends/Meta-Depends, would render them pretty useless. the vast majority of metapackage dependencies are moved from Depends to Recommends, so you can remove those Recommends manually without forcing removal of the metapackage; This already happens now, or did I miss something? Thanks for commenting, David -- . ''`. Debian developer | http://wiki.debian.org/DavidPaleino : :' : Linuxer #334216 --|-- http://www.hanskalabs.net/ `. `'` GPG: 1392B174 | http://snipr.com/qa_page `- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [RFC] DEP-6: Meta-Package debian/control field
Hi David, thanks for taking the initiative of improving the management of meta-packages. As you see now, it is a big project ! Like any major change in the package management system, the safest solution to the problem is patience: implement the solution in given release, let the users have update all their core package management programs in the next release, and start to distribute new meta-packages in the next next release. It looks like a long process, but it also remove a lot of constraints. And do not worry on having to wait… time files amazingly fast ! Have a nice day, and good luck to DEP-6. -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [RFC] DEP-6: Meta-Package debian/control field
On Sun, Dec 20, 2009 at 09:30:04PM +0100, David Paleino wrote: Ubuntu defines a special archive section, 'metapackages', which results in special tagging/handling of the Depends and Recommends of the package so that they're not autoremoved if the metapackage is removed. This is implemented in the high-level package management tools. Well, our proposal prospects something different: the metapackage is not removed (thus everything else is not autoremoved) if one of its Meta- Depends/Depends is removed. From what I can tell, the only difference between the two implementations is compatibility with disabling installation of Recommends by default. I don't think this is a good rationale for adding yet another package relationship field. The Recommends field is *already* defined in Policy to have the behavior you're looking for (installed by default but not a hard requirement), and I don't see any reason that metapackages should need the added complexity of a different field. In this scenario, with Recommends installed by default (the only sane model), On my host, Recommends are not installed by default, and this is configurable. A similar configuration, and meta-packages using Recommends instead of Depends/Meta-Depends, would render them pretty useless. There are good reasons for it to be configurable: - it's useful for debugging purposes - in cases of specific packages, disabling recommends-by-default and then hand-selecting the ones you want may be more efficient than installing all recommends and selecting those to remove afterwards - it's how we want buildds and developer build chroots to be configured, so that build-dependencies aren't overlooked because they're usually installed as recommends But that doesn't mean it makes sense for users to set this setting globally on their systems, or to design further complexity into our package manager to accomodate such configurations. the vast majority of metapackage dependencies are moved from Depends to Recommends, so you can remove those Recommends manually without forcing removal of the metapackage; This already happens now, or did I miss something? The difference is that the packages that are now listed as Depends would be moved to Recommends. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: [RFC] DEP-6: Meta-Package debian/control field
On Sun, Dec 20, 2009 at 06:11:46PM +0100, Andreas Metzler wrote: The current proposal is not backwards compatible since it fundamentally changes the meaning of Depends. Depends is transitive. If A depends on B, and B depends on C. A can rely on functionality proveided by C. Your proposal breaks that, since it allows removal of C (assuming B is a meta package), keeping it installed in a broken state. If A relies on functionality provided by C, then A should have a dependency on C; it's true that the transitivity certainly masks many of these absent depends, but their absence is still a bug, even if low-priority. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [RFC] DEP-6: Meta-Package debian/control field
On Sun, 20 Dec 2009, David Paleino wrote: Daniel Burrows wrote: [..] I actually would prefer a Meta-Depends sort of solution. The dependencies we're talking about are really not package dependencies in the normal sense at all, and we shouldn't be confusing them with normal dependencies. IMO, that basic conflation, while a convenient and expedient hack when it was introduced years ago, is the cause of our troubles. Well, we (me and Luca Bruno (not kaeso, the other one)) decided not to use Meta-Depends because that would've broken meta-packages installed with $non_compliant_tool . That's why you can use Breaks: $non_compliant_tool on new generation meta-packages. I also agree that the meaning of Depends shouldn't change at all with the introduction of this feature. We had this discussion recently on a dpkg bug report. http://bugs.debian.org/548661 Cheers, -- Raphaël Hertzog -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
