Re: Dependencies of metapackages
On mer., 2011-08-31 at 11:59 +0100, Wolodja Wentland wrote: Could you elaborate on your reasons and your intentions for making the distinction? Policy 7.2, mostly, and the fact depends are installed (obviously), recommends are installed by default (but that can be disabled and one can remove it safely) and suggests are just displayed. Do you have reasons for not changing Depends into Recommends? I will probably file bugs, but do not want to do so if I already know that the maintainer is not going to change it. I am sincerely interested and my only motivation is to make Debian a better distribution. I'm not going to change it if you don't have good reason for specific packages changes. Regrds, -- Yves-Alexis signature.asc Description: This is a digitally signed message part
Re: Dependencies of metapackages
* Josselin Mouette [2011-09-01 09:52 +0200]: I think we could solve a lot of those problems by treating metapackages specially in APT. Ubuntu has a section metapackages, introducing such a section in Debian could be the first step to treat metapackages specially. Carsten -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110902165452.ga26...@furrball.stateful.de
Re: Dependencies of metapackages
Wolodja Wentland babi...@gmail.com writes: is there a specific reason why metapackages depend rather then recommend packages they are meant to pull in? The rationale behind this question is [0] that we see a plethora of users in #debian who ask questions like: Why did apt remove all my system??⸘one!one!eleven! and we have to explain to them that it is because they decided to remove one of (typically) gnome's dependencies, which caused the metapackage to be removed as well. The solution is then to either mark all other dependencies as manually installed, install a smaller metapackage or a combination of those. Since turning these dependencies into Recommends: is apparently infeasible, it may be useful to amend APT to automatically mark the metapackage's dependencies as manually installed if the metapackage itself is so marked. Or do I miss something obvious with this approach? (Sorry, I'm not familiar with the subject. Beyond knowing to avoid metapackages at all costs, i. e.) […] -- FSF associate member #7257 Coming soon: Software Freedom Day http://mail.sf-day.org/lists/listinfo/ planning-ru (ru), sfd-discuss (en) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/867h5qamdt@gray.siamics.net
Re: Dependencies of metapackages
Le lundi 29 août 2011 à 16:40 +0100, Wolodja Wentland a écrit : is there a specific reason why metapackages depend rather then recommend packages they are meant to pull in? There are several reasons for that - at least for the GNOME ones. The first one is to guarantee that newly added packages are correctly installed. APT does a lot better than it used to on this matter, but there are still cases where it won’t install them. Then, there is the problem that versioned Recommends are useless, while we often want to guarantee that an optimal version combination is installed. Worse: they are ignored. To work around that we could use “Recommends: blah” and “Breaks: blah 3.0” but then the APT mechanisms will choose to remove blah instead of keeping the metapackage at a lower version. Finally, there’s the problem of keeping testing usable. You don’t want a metapackage to migrate until all the packages it brings have also migrated, otherwise testing systems could become unexpectedly unusable. I think we could solve a lot of those problems by treating metapackages specially in APT. For example, solutions removing such packages from the system should be given a lower priority. -- .''`. Josselin Mouette : :' : `. `' `- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1314863528.3246.583.camel@pi0307572
Re: Dependencies of metapackages
On Tue, Aug 30, 2011 at 17:37 +0200, Yves-Alexis Perez wrote: On mar., 2011-08-30 at 16:11 +0100, Wolodja Wentland wrote: I agree that a general change of all metapackages is probably not a good idea, but I think that changing the root-nodes of the metapackage tree (i.e. metapackages like gnome, xfce4, kde-full, ...) is a sensible change. It is in particular one that solves the problems without the need to introduce new package fields, change packaging tools or their semantics. If you think some dependencies in those metapackages are unneeded or too strong, you're welcome to open a wishlist bug against them. For xfce4, while I'm open to discussion, the distinction between depends/recommends/suggests is intended, and at first sight I don't see a need to change it. Could you elaborate on your reasons and your intentions for making the distinction? Do you have reasons for not changing Depends into Recommends? I will probably file bugs, but do not want to do so if I already know that the maintainer is not going to change it. I am sincerely interested and my only motivation is to make Debian a better distribution. It is just that I know that the behaviour discussed in this thread is a nuisance for a subset of our users and I wanted to gather additional input about different strategies to solve this. I tried to come up with a solution that does not require changes to the packaging tools, the introduction of new package fields or constitute a major change in the semantics of packages or tools. All that being said: I still have the opinion that metapackages *are* different from normal and virtual packages and that, in particular, the relations they define to other packages conflate distinct relations just because it eases implementation. (which is not inherently bad). -- Wolodja babi...@gmail.com 4096R/CAF14EFC 081C B7CD FF04 2BA9 94EA 36B2 8B7F 7D30 CAF1 4EFC signature.asc Description: Digital signature
Re: Dependencies of metapackages
On Mon, Aug 29, 2011 at 04:40:30PM +0100, Wolodja Wentland wrote: is there a specific reason why metapackages depend rather then recommend packages they are meant to pull in? The statement that metapackages depend from packages is not true in general. A counter example are those metapackages which are created using the Blends framework (blends-dev). It does not use Depends but rather Recommends and Suggests - basically for the reasons you are criticising in your mail. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110830072643.gb12...@an3as.eu
Re: Dependencies of metapackages
Andreas Tille andr...@an3as.eu (30/08/2011): On Mon, Aug 29, 2011 at 04:40:30PM +0100, Wolodja Wentland wrote: is there a specific reason why metapackages depend rather then recommend packages they are meant to pull in? The statement that metapackages depend from packages is not true in general. A counter example are those metapackages which are created using the Blends framework (blends-dev). It was never said *all* meta packages are using Depends (at least not AFAIR, and not in what your quoted). I suggest you pick random common examples: gnome-desktop-environment (or gnome), xfce4, lxde, xorg, firmware-linux, r-recommended, etc. Mraw, KiBi. signature.asc Description: Digital signature
Re: Dependencies of metapackages
On Tue, Aug 30, 2011 at 09:26 +0200, Andreas Tille wrote: On Mon, Aug 29, 2011 at 04:40:30PM +0100, Wolodja Wentland wrote: is there a specific reason why metapackages depend rather then recommend packages they are meant to pull in? The statement that metapackages depend from packages is not true in general. A counter example are those metapackages which are created using the Blends framework (blends-dev). It does not use Depends but rather Recommends and Suggests - basically for the reasons you are criticising in your mail. I never meant to imply that *all* metapackages use Depends. I just know from my experience with support in #debian that users frequently run into the problems I described earlier and my motivation is merely to make Debian a more pleasant and intuitively predictable distribution for our users. It is my impression that the problems mentioned in my initial mail can be solved by changing metapackages (like those mentioned by Cyril in his reply) to use Recommends instead of Depends. I am, however, not entirely sure if there are any good reasons for not doing this and therefore hoped to spur a discussion of this topic. What is problematic about this change or a general suggestion that metapackages should use Recommends instead of Depends? -- Wolodja babi...@gmail.com 4096R/CAF14EFC 081C B7CD FF04 2BA9 94EA 36B2 8B7F 7D30 CAF1 4EFC signature.asc Description: Digital signature
Re: Dependencies of metapackages
Wolodja Wentland babi...@gmail.com (30/08/2011): It is my impression that the problems mentioned in my initial mail can be solved by changing metapackages (like those mentioned by Cyril in his reply) to use Recommends instead of Depends. I am, however, not entirely sure if there are any good reasons for not doing this and therefore hoped to spur a discussion of this topic. What is problematic about this change or a general suggestion that metapackages should use Recommends instead of Depends? If you do that, you lose the distinction between packages that are absolutely required, and those that are only a recommendation, and can be skipped by the experienced users. If you look at xfce4, you can see it pulls by default xorg (which pulls in turn an X server and drivers), and a few extra items which are not strictly needed. For example, if you want to run xfce4 with an exported display, you don't really need an X server. Or desktop-base support. So if you know what you're doing, you can still use the meta package to pull the Depends, but skip some if not all Recommends. Mraw, KiBi. signature.asc Description: Digital signature
Re: Dependencies of metapackages
On Tue, Aug 30, 2011 at 11:27:48AM +0100, Wolodja Wentland wrote: is there a specific reason why metapackages depend rather then recommend packages they are meant to pull in? I never meant to imply that *all* metapackages use Depends. For my perception of your sentence at least a some was missing in your first mail. Without it it is a general statement. I just wanted to mention some exceptions from it and that these exceptions exist because of the reasons you gave. If you want to read it in other words: +1 for your arguments. It is my impression that the problems mentioned in my initial mail can be solved by changing metapackages (like those mentioned by Cyril in his reply) to use Recommends instead of Depends. +1 Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110830144648.gb21...@an3as.eu
Re: Dependencies of metapackages
On 30/08/2011 16:46, Andreas Tille wrote: On Tue, Aug 30, 2011 at 11:27:48AM +0100, Wolodja Wentland wrote: It is my impression that the problems mentioned in my initial mail can be solved by changing metapackages (like those mentioned by Cyril in his reply) to use Recommends instead of Depends. What happens when a new Recommends is added to a meta-package. Is it installed by default by APT ? Can we add version information (= X.Y) to Recommends? I'm not sure it is useful for the APT point of view. Regards Vincent -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4e5cfb47.2060...@free.fr
Re: Dependencies of metapackages
On Tue, Aug 30, 2011 at 12:32 +0200, Cyril Brulebois wrote: Wolodja Wentland babi...@gmail.com (30/08/2011): It is my impression that the problems mentioned in my initial mail can be solved by changing metapackages (like those mentioned by Cyril in his reply) to use Recommends instead of Depends. I am, however, not entirely sure if there are any good reasons for not doing this and therefore hoped to spur a discussion of this topic. What is problematic about this change or a general suggestion that metapackages should use Recommends instead of Depends? If you do that, you lose the distinction between packages that are absolutely required, and those that are only a recommendation, and can be skipped by the experienced users. If you look at xfce4, you can see it pulls by default xorg (which pulls in turn an X server and drivers), and a few extra items which are not strictly needed. For example, if you want to run xfce4 with an exported display, you don't really need an X server. Or desktop-base support. So if you know what you're doing, you can still use the meta package to pull the Depends, but skip some if not all Recommends. Thank you Cyril for mentioning this important point, which unfortunately also means that almost everything that can be done right now to remedy the situation is a compromise. It seems to me that the typical victims of this behaviour are not experienced users, but those that installed Debian in the default configuration with the Desktop task. After some time they might have enough experience to decide that they do not want a certain set of packages, but know nothing about metapackages and the way they behave. All they see is that apt is removing a huge number of packages if they attempt to remove one of the dependencies. They would, in the optimal case, know enough about Debian and the various number of metapackages to be able to work around this problem. Solutions (for gnome) include: * Mark all dependencies of the metapackage as manually installed: aptitude unmarkauto '~R^gnome$' '~RRecommends:^gnome$' * Install one of the smaller metapackages like gnome-session and/or explicitly mark packages they want to keep as manually installed. * Accept the fact that a particular package can not be removed without breaking their system. You are completely right that the distinction between required packages and recommendations is lost if the (large?) metapackages use Recommends for both types of dependencies. I see metapackages as convenience packages that allow the user to easily specify a set of related packages and would argue that what is really needed for, say, Gnome is specified in the gnome-session metapackage not the gnome package. IMHO it is much easier for experienced users to achieve what you described in your penultimate sentence than it is for inexperienced users to slim down their system. So, what can be done to make life easier for all those users that are bitten by this? * Change large metapackages to Recommend rather then Depend on sets of packages that comprise a certain task. - Experienced users can not use these packages to only install required packages. → What is really essential in these packages that is not already combined in a smaller metapackage? → Experienced users can easily specify the exact set of packages they want without these metapackages. + Inexperienced users can easily trim down their system without seeing the interface they use to communicate with the computer being removed. * Change the way metapackages are treated by packaging tools - I really dislike this idea (cf. DEP-6 thread) * Change d-i to incorporate a more fine-grained package/task selection - More complicated installation - Complete removal of gnome is harder as multiple metapackage might have to be removed. (i.e. all manually selected) - Only applies to initial installations * Do not change anything. * ... (?) I agree that a general change of all metapackages is probably not a good idea, but I think that changing the root-nodes of the metapackage tree (i.e. metapackages like gnome, xfce4, kde-full, ...) is a sensible change. It is in particular one that solves the problems without the need to introduce new package fields, change packaging tools or their semantics. -- Wolodja babi...@gmail.com 4096R/CAF14EFC 081C B7CD FF04 2BA9 94EA 36B2 8B7F 7D30 CAF1 4EFC signature.asc Description: Digital signature
Re: Dependencies of metapackages
Let me say this (i'm working on a new tsort you can say - but slowly as it's not my day job). if Virtual package is the same as meta package... (which ends up being a simple lookup before package list ordering / dropping) Why worry about Recommends or Suggests ? Only after dpkg develops a good install / uninstall list does it become important to consider tagging on extras: which is completely optional as user may say not to even try. Let me say one thing about libraries and dependancies: DON'T make virtuals more complicated with versions unless you are sure as shit it will fix past and current install difficulties and be compatible with apple / bsd and other pkg systems. it would be a making a far great casm than virtual already does to do so. My initial guess is that virtuals are meant to hide directness (ie, specific names and versions) so making virtuals more direct will really cause allot of problems forward and also backward. Though I'm in a hurry and cane write a paper on it right now :) Bye! Only by discussing and testing thoroughly do you know though. Vincent Danjean wrote: On 30/08/2011 16:46, Andreas Tille wrote: On Tue, Aug 30, 2011 at 11:27:48AM +0100, Wolodja Wentland wrote: It is my impression that the problems mentioned in my initial mail can be solved by changing metapackages (like those mentioned by Cyril in his reply) to use Recommends instead of Depends. What happens when a new Recommends is added to a meta-package. Is it installed by default by APT ? Can we add version information (= X.Y) to Recommends? I'm not sure it is useful for the APT point of view. Regards Vincent -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4e5d012f.2090...@cox.net
Re: Dependencies of metapackages
On mar., 2011-08-30 at 16:11 +0100, Wolodja Wentland wrote: I agree that a general change of all metapackages is probably not a good idea, but I think that changing the root-nodes of the metapackage tree (i.e. metapackages like gnome, xfce4, kde-full, ...) is a sensible change. It is in particular one that solves the problems without the need to introduce new package fields, change packaging tools or their semantics. If you think some dependencies in those metapackages are unneeded or too strong, you're welcome to open a wishlist bug against them. For xfce4, while I'm open to discussion, the distinction between depends/recommends/suggests is intended, and at first sight I don't see a need to change it. On a totally different scale, is it a good idea that automatic installation of recommends is recursive? It is a really tricky question, and I'm not sure there's *one* answer. In some cases you really want them (well, as long as you want automatic recommends), but not all. Regards, -- Yves-Alexis -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1314718667.2150.3.camel@oban
Re: Dependencies of metapackages
but if you mean strict meta as in it has no files but depends on real specific libraried packages ... as far as I know strict meta are already well versioned and any package, such as perl, acts as a meta in some way by depending on other versions of packages to fully install - in the sense of how you are discussing whether metas can have version - though it has a few initial files installed. what is important is that metas and virtuals are not mixed together and kept far apart is what I'd say Vincent Danjean wrote: On 30/08/2011 16:46, Andreas Tille wrote: On Tue, Aug 30, 2011 at 11:27:48AM +0100, Wolodja Wentland wrote: It is my impression that the problems mentioned in my initial mail can be solved by changing metapackages (like those mentioned by Cyril in his reply) to use Recommends instead of Depends. What happens when a new Recommends is added to a meta-package. Is it installed by default by APT ? Can we add version information (= X.Y) to Recommends? I'm not sure it is useful for the APT point of view. Regards Vincent -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4e5d05c1.4060...@cox.net
Dependencies of metapackages
Hi all, is there a specific reason why metapackages depend rather then recommend packages they are meant to pull in? The rationale behind this question is [0] that we see a plethora of users in #debian who ask questions like: Why did apt remove all my system??⸘one!one!eleven! and we have to explain to them that it is because they decided to remove one of (typically) gnome's dependencies, which caused the metapackage to be removed as well. The solution is then to either mark all other dependencies as manually installed, install a smaller metapackage or a combination of those. As this is a common problem of our users I was thinking why we don't make it easier for them to slim down their system after they've done a default installation. Are there any drawbacks to this change in metapackage semantics that I am not aware of? [0] The rationale is also more or less the same as the one formulated for DEP-6 http://dep.debian.net/deps/dep6/ -- Wolodja babi...@gmail.com 4096R/CAF14EFC 081C B7CD FF04 2BA9 94EA 36B2 8B7F 7D30 CAF1 4EFC signature.asc Description: Digital signature
Re: Dependencies of metapackages
On Mon, Aug 29, 2011 at 04:40:30PM +0100, Wolodja Wentland wrote: they decided to remove one of (typically) gnome's dependencies, which caused the metapackage to be removed as well. That also causes an effect of GNOME gets removed! even without any additional autoremoved packages :( -- WBR, wRAR signature.asc Description: Digital signature
