> X) Downgrade stuff to recommends
> ================================

> I do not consider this a solution, for reasons explained elsewhere,
> where my main concern is that it breaks the assumption that installing a
> platform (in this case, gnome) will install the whole thing, and it will
> be available for my use at any time.

> > Then some time later during upgrade it'll upgrade all packages
> > but will not install N-M; at the same time it'll install
> > new package that was added to Recommends in that new version.

> As far as I remember, it will not install new recommends.

> More or less, except that to the best of my knowledge, it will not
> install new recommends on upgrade. And that makes sense, and is good so,
> otherwise it will attempt to install all recommends I explicitly did not
> install on each upgrade - no thanks. (Or we need to introduce yet
> another complexity into the system, to mark packages as
> not-to-install-ever. I doubt we have that now... but perhaps hold on an
> uninstalled package works that way? I don't know.)

> Weeks later, when I want to watch a movie, at the end of the world, with
> no network connectivify, I realize that something pulled my movie player
> out of me.

> I would be very, very sad.

> Of course, silly me, why do I run unstable? And why don't I pay
> attention to what my upgrades do? Well, I run unstable because I work
> with it, and it has up-to-date stuff I have to work with. And running
> unstable is far easier than running testing and cherry-picking (did I
> mention I hate manual bookkeeping?). I do unattended upgrades, because I
> trust the system to keep everything I installed, installed. I installed
> the gnome meta-package because I want the full thing, bells, whistles
> and crap included.

> Thus, here's an example where Recommends *will break* an existing
> system.

> Oh, and since apt won't install new recommends on upgrade, to the best
> of my knowledge, I won't get totem back once the
> transition/breakage/whatever is fixed, either. While if it would be a
> dependency, the upgrade would abort, because it'd try to remove a
> package marked as manually installed.

> But similarly, if I ran stable, and one of the meta packages I installed
> had a recommends on a piece of software, and I try to install something
> that conflicts with it (either directly, or indirectly, via another meta
> package, for example), then this piece of software gets removed. I may
> or may not notice that - I might not even know wtf totem is, a novice
> user who first sees Linux certainly won't - so it gets removed.

> As far as I'm concerned, this defeats the purpose of the meta-package,
> because it breaks my expectation that whatever else it pulls in, will
> stay there as long as the meta is installed.

> Erm, how have I broken my system? I did not. (Turning Install-Recommends
> off is definitely not breaking my system, FYI.)

> > On 2012-07-10 15:32, Josselin Mouette wrote:
> >> Le mardi 10 juillet 2012 à 17:38 +0900, Miles Bader a écrit :
> >> > What's wrong with Recommends: in that case?  It seems to perfectly
> >> > match the "makes life easier for <common but not universal use-case
> >> > XXX>" scenario you describe.

> >> Recommends is wrong for metapackages because it gets upgrades very
> >> wrong. This is why it is used very marginally.

> > Standards should not depend on implementation details. I see zero
> > reasons why metapackages are (or should be) specific here. Whatever $it
> > that gets upgrades wrong should be fixed instead.

> But the purpose of the meta-package is to pull stuff in. Depends does
> that, Recommends does not, therefore Recommends is not appropriate for
> the task.

>> > On 2012-07-10 15:32, Josselin Mouette wrote:
>> >> Le mardi 10 juillet 2012 à 17:38 +0900, Miles Bader a écrit :
>> >> > What's wrong with Recommends: in that case?  It seems to perfectly
>> >> > match the "makes life easier for <common but not universal use-case
>> >> > XXX>" scenario you describe.

>> >> Recommends is wrong for metapackages because it gets upgrades very
>> >> wrong. This is why it is used very marginally.

>> > Standards should not depend on implementation details. I see zero
>> > reasons why metapackages are (or should be) specific here. Whatever $it
>> > that gets upgrades wrong should be fixed instead.

>> But the purpose of the meta-package is to pull stuff in. Depends does
>> that, Recommends does not, therefore Recommends is not appropriate for
>> the task.

> Of course it does. Five years ago, when apt didn't install recommends by
> default, recommends might not have been appropriate, but these days it
> is.

>> Instead of fighting for Recommends, which would break your system in
>> various interesting ways later on[1], there's a third solution: noone
>> stops anyone from uploading a gnome-minimal package, which depends on
>> gnome-session and a few selected other parts, without n-m.

> I would think it quite rude to trample on the gnome-* namespace unless
> this is well coordinated with the GNOME packagers.  If they're happy
> with it, that's a different situation.

>> Erm, how have I broken my system? I did not. (Turning Install-Recommends
>> off is definitely not breaking my system, FYI.)

> It means you are running with a non-default configuration and you should
> be aware of the side-effects.

>> X) Downgrade stuff to recommends
>> ================================

>> I do not consider this a solution, for reasons explained elsewhere,
>> where my main concern is that it breaks the assumption that installing a
>> platform (in this case, gnome) will install the whole thing, and it will
>> be available for my use at any time.

> Well, it will, in all but unusual installations :)

> Could you please elaborate on that? The only thing I can think of that
> would force some packages to not be installed (or removed) is a
> Conflicts (or unsatisfiable Depends, but this shouldn't happen in
> stable).

> Are you talking about testing or sid?

> IMO the main problem is:

> # aptitude remove package
> Following packages will be removed:
> [Big list with 100+ packages]

> Sorry, I thought we were talking about stable, why would something like
> that happen.

> But also keep in mind, that once a package is installed, adding new
> recommends will not pull those new things in on an upgrade.

>> > Then some time later during upgrade it'll upgrade all packages
>> > but will not install N-M; at the same time it'll install
>> > new package that was added to Recommends in that new version.

>> As far as I remember, it will not install new recommends.

> http://lists.debian.org/CAAZ6_fDTAydt1UBp08yf0d8L0JUSFFY1rZYHVmvztFCjeOc...@mail.gmail.com

>> Weeks later, when I want to watch a movie, at the end of the world, with
>> no network connectivify, I realize that something pulled my movie player
>> out of me.

>> I would be very, very sad.

>> Of course, silly me, why do I run unstable? And why don't I pay
>> attention to what my upgrades do? Well, I run unstable because I work
>> with it, and it has up-to-date stuff I have to work with. And running
>> unstable is far easier than running testing and cherry-picking (did I
>> mention I hate manual bookkeeping?). I do unattended upgrades, because I
>> trust the system to keep everything I installed, installed. I installed
>> the gnome meta-package because I want the full thing, bells, whistles
>> and crap included.

> Sorry, but IMNSHO running sid with unattended upgrades just asks for
> trouble. But then again IANADD, if Debian wants to optimize for this use
> case who am I to disagree? :)

>> Thus, here's an example where Recommends *will break* an existing
>> system.

>> Oh, and since apt won't install new recommends on upgrade, to the best
>> of my knowledge, I won't get totem back once the
>> transition/breakage/whatever is fixed, either. While if it would be a
>> dependency, the upgrade would abort, because it'd try to remove a
>> package marked as manually installed.

>> But similarly, if I ran stable, and one of the meta packages I installed
>> had a recommends on a piece of software, and I try to install something
>> that conflicts with it (either directly, or indirectly, via another meta
>> package, for example), then this piece of software gets removed. I may
>> or may not notice that - I might not even know wtf totem is, a novice
>> user who first sees Linux certainly won't - so it gets removed.

> Well, if the purpose of the Depends are to protect a novice from
> removing packages by mistake that surely a package manager offering to
> remove 100+ packages should definitely sound an alarm.

> Did you consider creating your own meta-package? It shouldn't take you
> more than 5 minutes to write an apt hook to get the control file and
> s/Recommends/Depends/

> > Instead of fighting for Recommends, which would break your system in
> > various interesting ways later on[1], there's a third solution: noone
> > stops anyone from uploading a gnome-minimal package, which depends on
> > gnome-session and a few selected other parts, without n-m.

> I would think it quite rude to trample on the gnome-* namespace unless
> this is well coordinated with the GNOME packagers.  If they're happy
> with it, that's a different situation.

> Er, no.

> Upstreams are not infallible, and are often quite fallible...

> Upstream's "view" is a good _default_, but such judgements should be
> made based on the reality on the ground.

> > Not so minimal if you want your gnome set to be up to date, including new
> > applications being installed.

> It is very minimal. 5 minutes of work. Been there, done that, posted the
> bulk of the solution, and a general outline of the rest of it to this
> list, in this very thread, multiple times.

> Please take some time to read it. But alas, I'll make it easy for you:

> If you want to install a meta-package, but without one of its
> dependencies, and want to keep up to date with it too, so you get all
> the new stuff added to it, and you also want to be able to remove the
> whole thing with one swift sweep, here's what you do:

> - Grab the control file of the meta-package
>   (~1 line in shell, use grep-aptavail)
> - Filter out unwanted packages from depends
>   (~5-6 lines in shell)
> - Create a local package, under a different name, with the updated
>   information
>   (~10-20 lines, use equivs)
> === 5 minutes so far ===
> - Push it into a local repository
>   (~2-3 lines, use whatever, reprepro, mini-dinstall, or cat <<EOF)
> - Put the local repo in sources.list
> - apt-get update & install your shiny new meta-package
> - Hook all that into Apt::Update::Post-invoke

> That's it. The whole thing is under a hundred lines, and easily doable
> within half an hour (for the record, I implemented all of the above this
> morning in 17 minutes while still half asleep).

> If you want to be super-cool, create a sourcable config file that tells
> the generator script what packages to filter out from which metas. Pack
> it up, ship a deb, everyone's happy.

> Even better, here's an alternative solution:

> - Grab a list of unwanted packages
> - Create a dummy package with an epoch of 99, using the same name the
>   unwanted packages.
> - Install them
> - Use the meta-package unmodified

> (Whole excercise doable in 10 minutes tops, including reading the equivs
> documentation.)

> All of that took a fraction of the time than arguing here on this list,
> about things that can already be solved *conveniently* by anyone caring
> enough, in multiple ways. Obviously, most people in this thread don't,
> as we'd already have a packaged solution if that weren't the case.

> And since noone seems to have cared enough to come up with a solution
> that works for *everyone* (upstream, novice and advanced users alike,
> and maintainers too), can we drop the subject now?

> > What we should do is to allow TWO levels of cherry-picking: the one for
> > advanced users who want to individually select every package, and the
> > other for users who want the whole set without a specific, molesting
> > package.

> We already have the first, it's called installing by hand. The second
> can easily be done, see above.

> > If that package is not a true dependency of the core of the set,
> > Recommends is more than justified.

> Upstream considers it a dependency in this case, part of a
> platform. If you don't want the full platform, don't install the full
> one, select the pieces you need - it is that easy.

> Similarly, if you don't want to install a full blown desktop system with
> a GUI, you don't select the desktop task when installing Debian. If you
> do want some little things later, you install those by hand.

> In case of gnome, the package pulls together what upstream considers the
> GNOME platform - it is that simple. If you don't need it all, don't
> install it all. If you want to follow the platform, but skip parts of
> it, I already presented two solutions above.

> You're welcome.

> My personal feeling is that this happens because people who use
> non-standard setups usually start by purging NM instead of trying to
> spend weeks reading the source code to contribute to it.

> # apt-get remove gstreamer-plugins-good

> Which will try to remove the whole world, including the meta, and that
> will ring alarm bells.

> Or in the recommends case:

> # apt-get remove gstreamer-plugin-good

> Which will remove a bunch of stuff, but leave the meta installed.

> In the latter case, you have gnome installed, without a video or audio
> player. Gnome sucks.

> I did not, as the existing meta-package works exactly how it should, and
> fulfills my expectations. If it bothers you so much, you can do the
> s/Depends/Recommends/ too. ;)

> > Er, no.

> > Upstreams are not infallible, and are often quite fallible...

> > Upstream's "view" is a good _default_, but such judgements should be
> > made based on the reality on the ground.

> In that case, recommends still is wrong. Either split the package then
> (and then both parties win), or drop a component completely (or demote
> to suggests).

> > But also keep in mind, that once a package is installed, adding new
> > recommends will not pull those new things in on an upgrade.

> I've been corrected, that this statement is not valid, and a
> dist-upgrade will pull them in. Sorry about that.

> However, Recommends: will not keep them installed, so if the meta is a
> platform, which should be intact and complete, recommends is still not
> an option.

> > No. At most it breaks *related* software.

> Exactly, that's why it's the "gnome-core" package that's RC-buggy, not
> network-manager.  Unless someone thinks a desktop environment's core
> function is to mess with the network, that is.

> It is very minimal. 5 minutes of work. Been there, done that, posted the
> bulk of the solution, and a general outline of the rest of it to this
> list, in this very thread, multiple times.

> Please take some time to read it. But alas, I'll make it easy for you:

> If you want to install a meta-package, but without one of its
> dependencies, and want to keep up to date with it too, so you get all
> the new stuff added to it, and you also want to be able to remove the
> whole thing with one swift sweep, here's what you do:

> - Grab the control file of the meta-package
>   (~1 line in shell, use grep-aptavail)
> - Filter out unwanted packages from depends
>   (~5-6 lines in shell)
> - Create a local package, under a different name, with the updated
>   information
>   (~10-20 lines, use equivs)
> === 5 minutes so far ===
> - Push it into a local repository
>   (~2-3 lines, use whatever, reprepro, mini-dinstall, or cat <<EOF)
> - Put the local repo in sources.list
> - apt-get update & install your shiny new meta-package
> - Hook all that into Apt::Update::Post-invoke

> That's it. The whole thing is under a hundred lines, and easily doable
> within half an hour (for the record, I implemented all of the above this
> morning in 17 minutes while still half asleep).

> If you want to be super-cool, create a sourcable config file that tells
> the generator script what packages to filter out from which metas. Pack
> it up, ship a deb, everyone's happy.

> Even better, here's an alternative solution:

> - Grab a list of unwanted packages
> - Create a dummy package with an epoch of 99, using the same name the
>   unwanted packages.
> - Install them
> - Use the meta-package unmodified

> (Whole excercise doable in 10 minutes tops, including reading the equivs
> documentation.)

> And since noone seems to have cared enough to come up with a solution
> that works for *everyone* (upstream, novice and advanced users alike,
> and maintainers too), can we drop the subject now?

> Upstream considers it a dependency in this case, part of a
> platform. If you don't want the full platform, don't install the full
> one, select the pieces you need - it is that easy.