Re: Package variant selection policy using meta packages
On Sat, Dec 22, 2012 at 02:57:56PM +0100, Joachim Breitner wrote: Hi, Am Samstag, den 22.12.2012, 14:39 +0200 schrieb Andrei POPESCU: On Sb, 22 dec 12, 13:17:32, Joachim Breitner wrote: Users tend to fall into one of three classes: A. Users that, if they have foo-dev installed, always also want foo-prof installed. B. Users that want to manually decide for what packages they want the -prof package and for what package not. C. Users who don’t want any -prof package around. Currently, we only really help user B. If user A installs foo-dev there is nothing that ensures that he gets foo-prof installed as well. And a foo-dev Recommends: foo-prof is not suitable because? because we cannot tell what the user will want. For example, a user of xmonad will not want -prof packages installed, and an addition 400MB of useless stuff on his computer is not in his, and hence our, interest. Also, a user from the class A wants a stronger guarantee than just Recommends, which is just a suggestion to the package manager, but not a a hard relation. No, that's not true; a Recommends is not a Suggests. Yes, I'm aware you didn't mean to say that. However, the very definition of Recommends implies that it is stronger than a suggestion, yet less than a hard dependency. It seems perfectly suited for your purpose. It covers case A perfectly, and B too, with some effort (but then, users in class B need to excert some effort anyway; the difference is only that now they need to decide which packages not to install when installing a -dev package, rather than which packages to install in addition to their -dev packages). It doesn't cover class C, but then that can be covered quite easily by having all packages with profiling information have something like Provides: haskell-profiling With that, users in class C can use equivs to create a package which Conflicts: haskell-profiling And then they'll never get any -prof packages installed, without any need for these metapackages. -- Copyshops should do vouchers. So that next time some bureaucracy requires you to mail a form in triplicate, you can mail it just once, add a voucher, and save on postage. -- 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/20121223211504.ge18...@grep.be
Re: Package variant selection policy using meta packages
Hi, Am Sonntag, den 23.12.2012, 22:15 +0100 schrieb Wouter Verhelst: No, that's not true; a Recommends is not a Suggests. That’s not what I said. But it is a suggestion in the sense that installing a package without the package that is Recommends is valid. It seems perfectly suited for your purpose. It covers case A perfectly, and B too, with some effort (but then, users in class B need to excert some effort anyway; the difference is only that now they need to decide which packages not to install when installing a -dev package, rather than which packages to install in addition to their -dev packages). I’m still not convinced. What if a user once decided not too care about -prof package, and not install them, or only some of them every time he needed them. Now he notices that this is annoying and wants all of them, for the -dev packages already installed. Recommends does not help him at all here, as they are taken only into consideration when installing a package. With my scheme, he could install i-want-all-prof-packages and the package manager will automatically install the missing -prof packages. Another point that has been missed so far: Class B should (probably) be the default, while class A should be possible. Even if Recommends would fit A perfectly the wrong variant would be the default. With meta-packages the approaches would be equally good, and ghc could have a Depends on i-want-some-prof-packages | i-want-all-prof-package to hint that the first one should be the default (whether this works should still be tested). It doesn't cover class C Ignore class C, I’m not sure if that is a demanded use case. OTOH, your solution is what I proposed, only that it’s only accessible to people who know equivs. My original question stands: Is there anything inherently wrong with my approach, or would it, if I find it the best solution, ok to employ it? The fact that Recommends might provide some of its features does not answer that. Greetings, Joachim -- Joachim nomeata Breitner Debian Developer nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata signature.asc Description: This is a digitally signed message part
Re: Package variant selection policy using meta packages
On Sun, Dec 23, 2012 at 10:31:19PM +0100, Joachim Breitner wrote: Hi, Am Sonntag, den 23.12.2012, 22:15 +0100 schrieb Wouter Verhelst: No, that's not true; a Recommends is not a Suggests. That’s not what I said. But it is a suggestion in the sense that installing a package without the package that is Recommends is valid. It seems perfectly suited for your purpose. It covers case A perfectly, and B too, with some effort (but then, users in class B need to excert some effort anyway; the difference is only that now they need to decide which packages not to install when installing a -dev package, rather than which packages to install in addition to their -dev packages). I’m still not convinced. What if a user once decided not too care about -prof package, and not install them, or only some of them every time he needed them. Now he notices that this is annoying and wants all of them, for the -dev packages already installed. Recommends does not help him at all here, as they are taken only into consideration when installing a package. You can easily search for those packages in aptitude, by using the following search string: ?and(?installed, ?broken-recommends(libghc.*prof$)) Sounds like all you need is just a bit of documentation which explains that. With my scheme, he could install i-want-all-prof-packages and the package manager will automatically install the missing -prof packages. Actually, that's not guaranteed, since your proposed i-want-all-prof-packages package doesn't actually have any relationship with the prof packages. As such, removing all haskell packages might be a correct solution to the problem of installing this package causes a shitload of package conflicts too and might be the solution the package manager chooses, depending on the packages which are already installed, the other operations that are being requested at the same time you install the metapackage, and the phase of the moon. In the worst case, the correct and wanted solution is 137 no, not that one, please calculate the next solution replies to aptitude away (and not available if you use another package manager, unless you manually install all -prof packages, which makes your metapackage useless). Another point that has been missed so far: Class B should (probably) be the default, while class A should be possible. Even if Recommends would fit A perfectly the wrong variant would be the default. With meta-packages the approaches would be equally good, and ghc could have a Depends on i-want-some-prof-packages | i-want-all-prof-package to hint that the first one should be the default (whether this works should still be tested). It doesn't cover class C Ignore class C, I’m not sure if that is a demanded use case. OTOH, your solution is what I proposed, only that it’s only accessible to people who know equivs. Not entirely. I propose a virtual package, you propose a non-virtual package. Other than that, yes, they are similar, but not quite the same thing. My original question stands: Is there anything inherently wrong with my approach, See above: it doesn't actually solve the problem, it only serves to confuse the package manager since it's not actually defined what your weird package relationships mean. or would it, if I find it the best solution, ok to employ it? The fact that Recommends might provide some of its features does not answer that. I suppose that's true. -- Copyshops should do vouchers. So that next time some bureaucracy requires you to mail a form in triplicate, you can mail it just once, add a voucher, and save on postage. -- 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/20121223221836.gh18...@grep.be
Re: Package variant selection policy using meta packages
Hi, Am Sonntag, den 23.12.2012, 23:18 +0100 schrieb Wouter Verhelst: With my scheme, he could install i-want-all-prof-packages and the package manager will automatically install the missing -prof packages. Actually, that's not guaranteed, since your proposed i-want-all-prof-packages package doesn't actually have any relationship with the prof packages. As such, removing all haskell packages might be a correct solution to the problem of installing this package causes a shitload of package conflicts too and might be the solution the package manager chooses, depending on the packages which are already installed, the other operations that are being requested at the same time you install the metapackage, and the phase of the moon. It’s true that the interaction with the package managers might render this problematic; this needs to be tested. Although in this case I think it should work, as apt-get, AFAIK, will always prefer installing packages over removing existing ones. Greetings, Joachim -- Joachim nomeata Breitner Debian Developer nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata signature.asc Description: This is a digitally signed message part
Package variant selection policy using meta packages
Dear developers, I’d like to get opinions on whether it is ok to (ab)use meta packages, alternative dependencies and conflicts to provide package selection policy features to our users that are not supported otherwise. Here is an example (and it is the use case that I am considering): Haskell libraries are always shipped in three different packages: * libghc-foo-dev ← The library itself * libghc-foo-prof ← Extra data only used when profiling code * libghc-foo-doc ← Documentation. Let’s look at -prof only(for -doc the same scheme would be useful). Users tend to fall into one of three classes: A. Users that, if they have foo-dev installed, always also want foo-prof installed. B. Users that want to manually decide for what packages they want the -prof package and for what package not. C. Users who don’t want any -prof package around. Currently, we only really help user B. If user A installs foo-dev there is nothing that ensures that he gets foo-prof installed as well. So my idea is to have a meta package for each use case. Note that this meta package should _not_ have to explicitly list all libghc-*-* packages, as it should not have to be changed when we add a new Haskell library (and it would make the testing migration even harder). So this should work (names just working titles, of course): I create three meta packages, named i-want-all-prof-packages, i-want-some-prof-packages, i-want-no-prof-packages. The package relations are then: i-want-all-prof-packages: Conflicts: i-want-some-prof-packages i-want-no-prof-packages i-want-no-prof-packages: Conflicts: i-want-some-prof-packages i-want-some-prof-packages: [no special relations] libghc-foo-dev: Depends: libghc-foo-prof | i-want-some-prof-packages | i-want-no-prof-package libghc-foo-prof: Conflicts: i-want-no-prof-package Clearly, only at most one of the three policy packages will be installed. * If i-want-all-prof-packages is installed, this means that the dependency of foo-dev implies foo-prof, as intended. * If i-want-some-prof-packages is installed, then the dependency of foo-dev is always fulfilled, so the user can decide what he wants or what not. * If i-want-no-prof-packages is installed, then the foo-dev dependency is fulfilled, but no -prof package can be installed. So all three use cases are supported, and our users happy. What do you think – should Debian employ such methods, or not? If not, why not? Greetings, Joachim PS: The existence of i-want-some-prof-packages, which has no dependencies, ensures that installability in general is not impaired, so this scheme would have /no/ bad effect on the testing migration. -- Joachim nomeata Breitner Debian Developer nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata signature.asc Description: This is a digitally signed message part
Re: Package variant selection policy using meta packages
On Sb, 22 dec 12, 13:17:32, Joachim Breitner wrote: Users tend to fall into one of three classes: A. Users that, if they have foo-dev installed, always also want foo-prof installed. B. Users that want to manually decide for what packages they want the -prof package and for what package not. C. Users who don’t want any -prof package around. Currently, we only really help user B. If user A installs foo-dev there is nothing that ensures that he gets foo-prof installed as well. And a foo-dev Recommends: foo-prof is not suitable because? Kind regards, Andrei -- Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic signature.asc Description: Digital signature
Re: Package variant selection policy using meta packages
Quoting Andrei POPESCU (2012-12-22 13:39:07) On Sb, 22 dec 12, 13:17:32, Joachim Breitner wrote: Users tend to fall into one of three classes: A. Users that, if they have foo-dev installed, always also want foo-prof installed. B. Users that want to manually decide for what packages they want the -prof package and for what package not. C. Users who don’t want any -prof package around. Currently, we only really help user B. If user A installs foo-dev there is nothing that ensures that he gets foo-prof installed as well. And a foo-dev Recommends: foo-prof is not suitable because? Recommends are for relations suitable for most users, not some class of users. - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Package variant selection policy using meta packages
On Sat, 22 Dec 2012 14:24:46 +0100 Jonas Smedegaard d...@jones.dk wrote: Quoting Andrei POPESCU (2012-12-22 13:39:07) On Sb, 22 dec 12, 13:17:32, Joachim Breitner wrote: Users tend to fall into one of three classes: A. Users that, if they have foo-dev installed, always also want foo-prof installed. B. Users that want to manually decide for what packages they want the -prof package and for what package not. C. Users who don’t want any -prof package around. Currently, we only really help user B. If user A installs foo-dev there is nothing that ensures that he gets foo-prof installed as well. And a foo-dev Recommends: foo-prof is not suitable because? Recommends are for relations suitable for most users, not some class of users. In this case, the only difference is that using Recommends doesn't distinguish between cases B C. I don't see that as a problem. IMHO, actively preventing the installation of optional dependencies is not something which actually warrants support. None of these packages get installed by default, simply disabling the installation of Recommends by default meets all the requirements of cases B C without making an artificial block between the two. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpMllDwmDng0.pgp Description: PGP signature
Re: Package variant selection policy using meta packages
Hi, Am Samstag, den 22.12.2012, 14:39 +0200 schrieb Andrei POPESCU: On Sb, 22 dec 12, 13:17:32, Joachim Breitner wrote: Users tend to fall into one of three classes: A. Users that, if they have foo-dev installed, always also want foo-prof installed. B. Users that want to manually decide for what packages they want the -prof package and for what package not. C. Users who don’t want any -prof package around. Currently, we only really help user B. If user A installs foo-dev there is nothing that ensures that he gets foo-prof installed as well. And a foo-dev Recommends: foo-prof is not suitable because? because we cannot tell what the user will want. For example, a user of xmonad will not want -prof packages installed, and an addition 400MB of useless stuff on his computer is not in his, and hence our, interest. Also, a user from the class A wants a stronger guarantee than just Recommends, which is just a suggestion to the package manager, but not a a hard relation. With the i-want-all-prof-package metapackage it is guaranteed that for every -dev package, there is the corresponding -doc package installed. Am Samstag, den 22.12.2012, 13:32 + schrieb Neil Williams: IMHO, actively preventing the installation of optional dependencies is not something which actually warrants support. I admit that use case C might not be as useful as the difference between B and A, but it doesn’t hurt either (assuming a meta-package based approach is taken for A and B). None of these packages get installed by default, simply disabling the installation of Recommends by default meets all the requirements of cases B C without making an artificial block between the two. I find this a bit coarsely grained. I might be a user in class B or C, but besides that I certainly want to follow whatever the maintainer of a package recommends me to install. Disabling the installation of Recommends would change the behavior of _all_ Debian package. I don’t think this is a good solution. Greetings, Joachim -- Joachim nomeata Breitner Debian Developer nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata signature.asc Description: This is a digitally signed message part
Re: Package variant selection policy using meta packages
On Sat, 22 Dec 2012 14:57:56 +0100 Joachim Breitner nome...@debian.org wrote: Am Samstag, den 22.12.2012, 14:39 +0200 schrieb Andrei POPESCU: On Sb, 22 dec 12, 13:17:32, Joachim Breitner wrote: Users tend to fall into one of three classes: A. Users that, if they have foo-dev installed, always also want foo-prof installed. B. Users that want to manually decide for what packages they want the -prof package and for what package not. C. Users who don’t want any -prof package around. Currently, we only really help user B. If user A installs foo-dev there is nothing that ensures that he gets foo-prof installed as well. And a foo-dev Recommends: foo-prof is not suitable because? because we cannot tell what the user will want. For example, a user of xmonad will not want -prof packages installed, and an addition 400MB of useless stuff on his computer is not in his, and hence our, interest. apt-get --no-install-recommends xmonad-prof ... Also, a user from the class A wants a stronger guarantee than just Recommends, which is just a suggestion to the package manager, but not a a hard relation. With the i-want-all-prof-package metapackage it is guaranteed that for every -dev package, there is the corresponding -doc package installed. I don't see why this is necessary. Recommends is a strong guarantee for most cases, it is also sufficiently flexible for those who want more control. Individual packages can check for extras, just like devscripts does. (I find it hard to believe that anyone except devscripts maintainers actually needs all of the Recommends: listed for devscripts.) Am Samstag, den 22.12.2012, 13:32 + schrieb Neil Williams: IMHO, actively preventing the installation of optional dependencies is not something which actually warrants support. I admit that use case C might not be as useful as the difference between B and A, but it doesn’t hurt either (assuming a meta-package based approach is taken for A and B). None of these packages get installed by default, simply disabling the installation of Recommends by default meets all the requirements of cases B C without making an artificial block between the two. I find this a bit coarsely grained. I might be a user in class B or C, but besides that I certainly want to follow whatever the maintainer of a package recommends me to install. Disabling the installation of Recommends would change the behavior of _all_ Debian package. I don’t think this is a good solution. It doesn't have to affect all packages. --no-install-recommends is your friend. What's more, package managers like synaptic will clearly show which packages are available as Recommends but which weren't installed. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpyInWAsFuwd.pgp Description: PGP signature
Re: Package variant selection policy using meta packages
[Joachim Breitner] And a foo-dev Recommends: foo-prof is not suitable because? because we cannot tell what the user will want. For example, a user of xmonad will not want -prof packages installed, and an addition 400MB of useless stuff on his computer is not in his, and hence our, interest. So, it appears xmonad is a window manager. It seems a fair question why someone who runs a window manager needs -dev packages at all, let alone -prof packages. According to the package description, you only need the -dev package if you actually plan to configure the window manager instead of using its defaults. Which presumably most people do, so I guess the Recommends makes sense. Excpet for the part where this requires one or more -dev packages at all. It looks as though configuring xmonad involves _recompiling_ it. What is this, an old school Unix kernel? I'm confused. Peter -- 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/20121222185144.gp4...@p12n.org
Re: Package variant selection policy using meta packages
Hi, Am Samstag, den 22.12.2012, 12:51 -0600 schrieb Peter Samuelson: According to the package description, you only need the -dev package if you actually plan to configure the window manager instead of using its defaults. Which presumably most people do, so I guess the Recommends makes sense. Excpet for the part where this requires one or more -dev packages at all. It looks as though configuring xmonad involves _recompiling_ it. What is this, an old school Unix kernel? I'm confused. this is getting off topic, but let me lessen your confusion: The popularity of xmonad lies in the fact that to configure it, you have the full power of a high level programming language available. The defaults are quite minimalistic, so most people will do that and willneed the -dev packages. However, they have no interest in the -prof packages altogether; this policy decision is what I want to make easier for the user to express and enforce. Greetings, Joachim -- Joachim nomeata Breitner Debian Developer nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata signature.asc Description: This is a digitally signed message part
