Re: Metapackage dependencies: "Depends" or "Recommends"?

[Marc Haber]

On Sat, 01 Aug 2015 08:55:03 +1000, Russell Stuart
 wrote:
>For my servers it's different.  The inherent ambiguity of Debian
>dependency system that libapt tries hide becomes intolerable, meaning I
>don't want something to just choose between the possibilities on my
>behalf, I want to be informed so I can see the choices and have my
>decision explicitly recorded to I can repeat it.

debfoster?

>Leaving garbage
>packages (think "garbage" as in garbage collector) lying around on
>servers that are supposed to be clones left alone to maintain themselves
>for a while is equally unacceptable.

Playing with servers that are supposed to be clones, even adminning
them with manual ssh interaction will make them lose their clone
property in absolutely not ime, turning them into snowflakes[1].

Automated systems are needed for that. And even then, a machine is to
be considered a snowflake once a person has been root on them.

Greetings
Marc

[1] all alike, but different
-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/e1zlqwc-00061d...@swivel.zugschlus.de

Re: Metapackage dependencies: "Depends" or "Recommends"?

[Russell Stuart]

On Thu, 2015-07-30 at 08:57 +0200, David Kalnischkies wrote:
> This example makes it quite obvious that your requirements are "keep
> a minimal set of packages installed" while the requirement of libapt's
> autoremove is "suggest only packages for removal which are completely
> safe to remove".

If "Suggest only packages for removal which are completely safe to
remove"  is supposed to be "list all which are completely safe to
remove" then it doesn't manage to do that either.  It fails given
circular references, ie A depends on B depends on C depends on A.

I guess it's designed for the "cleanup packages I played with for a
short while on my laptop" use case.  It does a sort of OK job at that.
Only sort of, because when you move across flag days the dregs left
libapt leaves behind can get it confused over which packages should
removed so the upgrade can proceed.

For my servers it's different.  The inherent ambiguity of Debian
dependency system that libapt tries hide becomes intolerable, meaning I
don't want something to just choose between the possibilities on my
behalf, I want to be informed so I can see the choices and have my
decision explicitly recorded to I can repeat it.  Leaving garbage
packages (think "garbage" as in garbage collector) lying around on
servers that are supposed to be clones left alone to maintain themselves
for a while is equally unacceptable.

In the end I gave up up on libapt and wrote my own dependency resolver.
Fortunately libapt makes that relatively easy because it's API gives you
access to all its internal working so you can re-use most of it.


signature.asc
Description: This is a digitally signed message part

Re: Metapackage dependencies: "Depends" or "Recommends"?

[Marvin Renich]

* Neil Williams  [150729 03:30]:
> I'd still use Depends in the metapackage. e.g. foo-server has lots of
> strict dependencies without which is simply won't install or start.
> foo-client has less dependencies and a few Recommends because the
> client can work for a range of usecases and not everyone needs every
> use case.
> 
> For those people who *do* want the assurance that every possible use
> case can work, then a foo metapackage would Depend on foo-server and
> foo-client and *all* of the Recommends of foo-client, possibly
> including even a few of the Suggests of foo-client.

For those people, don't change the default Apt::Install-Recommends and
you get the desired behavior with metapackages that use Recommends.  But
those of us who want most, but not all, of a metapackage can still get
what we want, too (with either setting of Install-Recommends).

If a metapackage uses Depends, the only way to install all but one
subpackage from the metapackage is to manually install all the desired
subpackages; but then you do not get the auto-installed behavior, so you
cannot easily remove the (non-)metapackage.  You also do not get the
benefits of updates to the contents of the metapackage.

No downside to Recommends; no upside to Depends.

Think of Recommends as "defaults to Depends, but can easily be
overridden by the user at install time".

Depends should be used when not installing the package causes functional
breakage rather than logical breakage or loss of functionality.

Recommends should be used when not installing the package makes sense if
the user is willing to put up with reduced functionality.

I think much of this debate is caused by users who set
Install-Recommends to false, but then want some of the benefits of
leaving it at the default of true.

I do set Install-Recommends to false, but I understand the trade-off I
am making.  I mostly use the aptitude curses interface, and I take a
little more time to go through the list of Recommended packages to
select the ones I want before pressing g a second time.  And yes, I do
mark those packages as automatically installed.

Using Recommends allows the user to choose which side of the trade-off
to be on.  Using Depends forces the "install everything, no opportunity
to spend a few extra seconds to choose what you want" on everybody.

...Marvin


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150731121623.gk21...@basil.wdw

Re: Metapackage dependencies: "Depends" or "Recommends"?

[Josh Triplett]

Ole Streicher wrote:
> Josh Triplett  writes:
> > The whole point of my metapackages is that absolutely everything
> > *except* those metapackages is marked as "automatically installed".
> > There's no programmatic way to distinguish between "Recommends that
> > should be installed" and "Recommends that should not be installed"; that
> > would be per-machine state information, which is exactly what I'm trying
> > to avoid.
> 
> What is "recommends that should not be installed"? It sounds a bit
> contradicting to me. Why don't you use "Suggests" for that?

I'm not talking about the dependencies of my metapackages; I only use
Depends and Conflicts in those.  I'm talking about the Recommends of
packages in Debian.  And there are quite a few of those that I do indeed
think ought to use Suggests.

> > So I turn off Recommends and make sure Depends reflect the packages I
> > want installed.
> 
> I think this is abusing the dependencies. The Policy has the hint that
> Recommends: is for everything that is usually installed except in
> special situations. Why would one turn them off by default???
> (... except for special situations)

That's what Policy says, yes.  That doesn't mean all Recommends are
sensible, and in practice, it's more common that I *don't* want them
than that I do.

> > I suppose in theory I could turn Recommends back on and then add
> > Conflicts in my metapackages for the Recommends that shouldn't be
> > installed, but a quick check on my current system shows hundreds of
> > uninstalled packages on my system that are Recommends of installed
> > packages.  That's more packages than I currently have in the Depends of
> > my metapackages; maintaining that doesn't seem practical.
> 
> At least, I don't get this. Can you make an example here?

Sure.  Here are a few packages that are Recommends of packages I do
depend on, but that I don't want installed:

- default-mta
- ppp
- valgrind-dbg (323MB of debug symbols)
- xpdf
- libltdl-dev (anything that needs this should have a Depends on it)
- locales (not since libc-bin started shipping C.UTF-8)
- mailx (as provided by bsd-mailx and similar)
- Piles and piles of extra Perl modules
- busybox-static

Of those, only locales seems at all justifiable as something that should
almost always be co-installed.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150730214842.GA20216@x

Re: Metapackage dependencies: "Depends" or "Recommends"?

[Ole Streicher]

Josh Triplett  writes:
> The whole point of my metapackages is that absolutely everything
> *except* those metapackages is marked as "automatically installed".
> There's no programmatic way to distinguish between "Recommends that
> should be installed" and "Recommends that should not be installed"; that
> would be per-machine state information, which is exactly what I'm trying
> to avoid.

What is "recommends that should not be installed"? It sounds a bit
contradicting to me. Why don't you use "Suggests" for that?

> So I turn off Recommends and make sure Depends reflect the packages I
> want installed.

I think this is abusing the dependencies. The Policy has the hint that
Recommends: is for everything that is usually installed except in
special situations. Why would one turn them off by default???
(... except for special situations)

> I suppose in theory I could turn Recommends back on and then add
> Conflicts in my metapackages for the Recommends that shouldn't be
> installed, but a quick check on my current system shows hundreds of
> uninstalled packages on my system that are Recommends of installed
> packages.  That's more packages than I currently have in the Depends of
> my metapackages; maintaining that doesn't seem practical.

At least, I don't get this. Can you make an example here?

Best regards

Ole


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87twslr07i@debian.org

Re: Metapackage dependencies: "Depends" or "Recommends"?

[Josh Triplett]

Marvin Renich wrote:
> * Josh Triplett  [150729 17:18]:
> > Ole Streicher wrote:
> > > Other packages will never depend on this metapackage; they will rather
> > > depend on the individual programs.
> > 
> > Other packages *in Debian* will not.  I actually build a pile of
> > personal metapackages to set up systems, and many of their dependencies
> > are metapackages.  If metapackages start using Recommends, that would be
> > quite inconvenient, as it would mean that I'd have to manually copy the
> > list of dependencies into my metapackage (and update it if the set of
> > needed packages changes) rather than just depending on the metapackage.
> 
> I don't understand this.  Why would having a Debian metapackage A which
> _correctly_ uses Recommends

[Considering that this is the whole point of this mail thread,
"correctly" is a bit presumptuous.]

> make your personal metapackage B which
> Depends on A fail to install the recommended packages from A?

The whole point of my metapackages is that absolutely everything
*except* those metapackages is marked as "automatically installed".
There's no programmatic way to distinguish between "Recommends that
should be installed" and "Recommends that should not be installed"; that
would be per-machine state information, which is exactly what I'm trying
to avoid.  So I turn off Recommends and make sure Depends reflect the
packages I want installed.

I suppose in theory I could turn Recommends back on and then add
Conflicts in my metapackages for the Recommends that shouldn't be
installed, but a quick check on my current system shows hundreds of
uninstalled packages on my system that are Recommends of installed
packages.  That's more packages than I currently have in the Depends of
my metapackages; maintaining that doesn't seem practical.

Someday, perhaps I can turn Recommends back on, but for right now, there
are far too many spurious recommends both in the core debootstrap set
and in the average package to consider doing so.  On the bright side,
there's a lot of work going on right now to prune both the core
debootstrap set and its Depends/Recommends.

- Josh Triplett


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150730175105.GA3700@jtriplet-mobl1

Re: Metapackage dependencies: "Depends" or "Recommends"?

[Nikolaus Rath]

On Jul 30 2015, David Kalnischkies  wrote:
> On Wed, Jul 29, 2015 at 10:45:01AM -0700, Nikolaus Rath wrote:
>> The only think it doesn't yet do is that if
>> 
>> - a is automatically installed
>> - b is automatically installed
>> - c is manually installed and depends on a|b
>> 
>> Either a or b can be removed. But I don't think apt* handled that either.
>
> This example makes it quite obvious that your requirements are "keep
> a minimal set of packages installed" while the requirement of libapt's
> autoremove is "suggest only packages for removal which are completely
> safe to remove".

Yes (though the main point of my email was to point out another way to
get rid of dependencies after a metapackage has been uninstalled).

> An algorithm can't reasonably decide if C is using A or B (or both) to
> provide one of its features (the one which is the reason for the
> depends, so that must be a pretty important feature as C is so useless
> without it that it is better removed).

Indeed. But debfoster is designed to be interactive, so it could easily
ask if the user wants to remove one of them, or keep both.

> Of course, a technically adapt user can decide which one is really
> used/needed by C and/or revise his decision mistake later on by
> reinstalling a package, but this is a maintenance cost – and a cost
> libapt doesn't want to nor can force upon all its users.

Yeah. This my hope that maybe this will be added to debfoster at some
point.



Best,
-Nikolaus

-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

 »Time flies like an arrow, fruit flies like a Banana.«


signature.asc
Description: PGP signature

Re: Metapackage dependencies: "Depends" or "Recommends"?

[David Kalnischkies]

On Wed, Jul 29, 2015 at 10:45:01AM -0700, Nikolaus Rath wrote:
> The only think it doesn't yet do is that if
> 
> - a is automatically installed
> - b is automatically installed
> - c is manually installed and depends on a|b
> 
> Either a or b can be removed. But I don't think apt* handled that either.

This example makes it quite obvious that your requirements are "keep
a minimal set of packages installed" while the requirement of libapt's
autoremove is "suggest only packages for removal which are completely
safe to remove".


An algorithm can't reasonably decide if C is using A or B (or both) to
provide one of its features (the one which is the reason for the
depends, so that must be a pretty important feature as C is so useless
without it that it is better removed).

Even if there is no configuration needed to use A or B, the usage
experience of iceweasel and w3m might be different, even if they are
both www-browser's.

Of course, a technically adapt user can decide which one is really
used/needed by C and/or revise his decision mistake later on by
reinstalling a package, but this is a maintenance cost – and a cost
libapt doesn't want to nor can force upon all its users.


Good thing that C isn't depending on 'apt | debfoster' for their ability
to remove unused dependencies as even if they have the same task, they
have totally different presets and target audiences…


Best regards

David Kalnischkies


signature.asc
Description: Digital signature

Re: Metapackage dependencies: "Depends" or "Recommends"?

[Marvin Renich]

* Josh Triplett  [150729 17:18]:
> Ole Streicher wrote:
> > Other packages will never depend on this metapackage; they will rather
> > depend on the individual programs.
> 
> Other packages *in Debian* will not.  I actually build a pile of
> personal metapackages to set up systems, and many of their dependencies
> are metapackages.  If metapackages start using Recommends, that would be
> quite inconvenient, as it would mean that I'd have to manually copy the
> list of dependencies into my metapackage (and update it if the set of
> needed packages changes) rather than just depending on the metapackage.

I don't understand this.  Why would having a Debian metapackage A which
_correctly_ uses Recommends make your personal metapackage B which
Depends on A fail to install the recommended packages from A?

Even if it did, how would that justify misusing the dependencies?

...Marvin


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150729213239.gj21...@basil.wdw

Re: Metapackage dependencies: "Depends" or "Recommends"?

[Josh Triplett]

Ole Streicher wrote:
> Other packages will never depend on this metapackage; they will rather
> depend on the individual programs.

Other packages *in Debian* will not.  I actually build a pile of
personal metapackages to set up systems, and many of their dependencies
are metapackages.  If metapackages start using Recommends, that would be
quite inconvenient, as it would mean that I'd have to manually copy the
list of dependencies into my metapackage (and update it if the set of
needed packages changes) rather than just depending on the metapackage.

- Josh Triplett


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150729211052.GA12548@jtriplet-mobl1

Re: Metapackage dependencies: "Depends" or "Recommends"?

[Nikolaus Rath]

On Jul 28 2015, Ole Streicher  wrote:
> Ben Hutchings  writes:
>> Installation of a package from the 'metapackages' section does *not*
>> mark its dependencies as automatically installed.
>
> Really? So, if someone would install a metapackage (for a test), and
> then later uninstall it, its dependencies will remain on the system?
>
> Is there any simple way to remove them?

Use debfoster to keep track of automatically/manually installed
packages. I think it works much better than apt and aptitude.

The only think it doesn't yet do is that if

- a is automatically installed
- b is automatically installed
- c is manually installed and depends on a|b

Either a or b can be removed. But I don't think apt* handled that either.

Best,
-Nikolaus

-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

 »Time flies like an arrow, fruit flies like a Banana.«


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87si867t9e@thinkpad.rath.org

Re: Metapackage dependencies: "Depends" or "Recommends"?

[Andreas Tille]

Hi,

On Wed, Jul 29, 2015 at 05:30:07PM +0200, Ole Streicher wrote:
> Andreas Tille  writes:
> > On Wed, Jul 29, 2015 at 04:11:12PM +0200, Ole Streicher wrote:
> >> Marvin Renich  writes:
> >> > A metapackage should not be used as a bat to beat users into installing
> >> > ALL of something.  It should be a tool to help users install all of
> >> > something if they wish, but users should still have as much control as
> >> > is reasonable to pick and choose a partial subset if it works for them.
> >> 
> >> Couldn't that be carved in stone^UPolicy?
> >
> > I admit I have not verified policy whether it is that drastically but
> > the paragraph above is what I understood as rough consensus in all
> > discussion about this.
> 
> It seems that some ftp-masters have a different opinion about this. And
> the thread shows, that there are others that won't agree here (see the
> xfce argumentation).

That's why I wrote **rough** consensus.  There is some friction in the
threads about this (otherwise there would be no discussion) but my
reading of all threads was that most people agree upon "Recommends" and
the arguments sounded more convincing to me.  I agree that ironing out
this in policy precisely could help ending this kind of discussions.

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: https://lists.debian.org/20150729160806.gr25...@an3as.eu

Re: Metapackage dependencies: "Depends" or "Recommends"?

[Ole Streicher]

Andreas Tille  writes:
> On Wed, Jul 29, 2015 at 04:11:12PM +0200, Ole Streicher wrote:
>> Marvin Renich  writes:
>> > A metapackage should not be used as a bat to beat users into installing
>> > ALL of something.  It should be a tool to help users install all of
>> > something if they wish, but users should still have as much control as
>> > is reasonable to pick and choose a partial subset if it works for them.
>> 
>> Couldn't that be carved in stone^UPolicy?
>
> I admit I have not verified policy whether it is that drastically but
> the paragraph above is what I understood as rough consensus in all
> discussion about this.

It seems that some ftp-masters have a different opinion about this. And
the thread shows, that there are others that won't agree here (see the
xfce argumentation).

Cheers

Ole


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/874mknrngg@debian.org

Re: Metapackage dependencies: "Depends" or "Recommends"?

[Andreas Tille]

On Wed, Jul 29, 2015 at 04:11:12PM +0200, Ole Streicher wrote:
> Marvin Renich  writes:
> > A metapackage should not be used as a bat to beat users into installing
> > ALL of something.  It should be a tool to help users install all of
> > something if they wish, but users should still have as much control as
> > is reasonable to pick and choose a partial subset if it works for them.
> 
> Couldn't that be carved in stone^UPolicy?

I admit I have not verified policy whether it is that drastically but
the paragraph above is what I understood as rough consensus in all
discussion about this.  These come up periodically about every six
monthes.

I guess if you think policy should be more clear about this the
authors will welcome a patch you can file in a bug report.

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: https://lists.debian.org/20150729152004.gn25...@an3as.eu

Re: Metapackage dependencies: "Depends" or "Recommends"?

[Ole Streicher]

Marvin Renich  writes:
> A metapackage should not be used as a bat to beat users into installing
> ALL of something.  It should be a tool to help users install all of
> something if they wish, but users should still have as much control as
> is reasonable to pick and choose a partial subset if it works for them.

Couldn't that be carved in stone^UPolicy?

Cheers

Ole


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/ytzpp3bf3zz@news.ole.ath.cx

Re: Metapackage dependencies: "Depends" or "Recommends"?

[Marvin Renich]

* Simon McVittie  [150728 08:55]:
> On 28/07/15 13:08, Marvin Renich wrote:
> > There is no downside to using Recommends and no upside to using Depends
> > for metapackages.
> 
> I don't think it's that simple; it comes down to a question of what the
> metapackage "means", which is a design question for its maintainer.
> 
> For metapackages that exist to make upgrades work ("dummy packages"),
> usually only Depends make sense: the package's entire purpose is to make
> sure old dependencies pull in what's needed.

Agreed.  Transitional packages are a separate issue.

> Tasks and task-like metapackages can be a mixture of both. It would make
> no sense for xfce4 to drop its Depends on xfwm4 down to a Recommends: if
> you don't have xfwm4, it is simply not true that you have "the core
> packages of the Xfce4 desktop environment" and the package database
> shouldn't claim that you do.

I still disagree.  If I want most of the core xfce4, but not quite all,
I should be able to install the metapackage and remove one or two items.
Both window manager and file manager are specifically things I might
wish to replace.  Your example is a very good demonstration of why
Recommends is appropriate.

> Perhaps the right question to be asking is: if foo has a RC bug, does
> that inherently make the task-bar metapackage unreleasable? If yes, then
> task-bar Depends on foo; if no, then task-bar Recommends (or even
> Suggests) foo.

No.  If foo has an RC bug, any package that would be functionally broken
should have a Depends.  The metapackage might be logically broken^W less
useful, but it is not functionally broken.

> Applying that logic to the xfce4 metapackage: if xfwm4 had a RC bug and
> got kicked out of testing, then the XFCE suite would not be not usable,
> so we should also consider xfce4 to be RC-buggy.  Good; it should have a
> Depends, which it does.

If xfwm4 had an RC bug, the XFCE suite may be logically broken, and the
maintainers may not wish to distribute the rest of the XFCE packages
without it, which might mean removing the metapackage xfce4.  But using
a Depends in the metapackage is not necessary to accomplish that.

If some of the other XFCE packages require xfwm4 and will break if you
use a different window manager, then they (the non-metapackages) should
have an appropriate Depends.

A metapackage should not be used as a bat to beat users into installing
ALL of something.  It should be a tool to help users install all of
something if they wish, but users should still have as much control as
is reasonable to pick and choose a partial subset if it works for them.

...Marvin


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150729140352.gi21...@basil.wdw

Re: Metapackage dependencies: "Depends" or "Recommends"?

[Marvin Renich]

* Andreas Tille  [150729 04:14]:
> On Tue, Jul 28, 2015 at 10:51:02AM -0700, Russ Allbery wrote:
> > > I'm sure this is personal taste, and in the end it won't matter for most
> > > people (except folks who don't install Recommends, but they're going to
> > > break their system regardless),
> > 
> > I've had Recommends disabled for something like five years.  My systems
> > have yet to break.  :)
> 
> And you did so because you are not a typical user of metapackages due to
> your deep insight into the packaging system and things you need. 

Exactly.  The point is that if metapackages use Depends, advanced users
cannot use the metapackages in advanced ways.  For the naive user, using
Recommends gets the desired effect, but still allows the advanced user
to pick and choose.  No downside to Recommends, no upside to Depends.

...Marvin


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150729133539.gh21...@basil.wdw

Re: Metapackage dependencies: "Depends" or "Recommends"?

[Jonas Smedegaard]

Quoting Adam D. Barratt (2015-07-28 20:02:39)
> On Tue, 2015-07-28 at 17:22 +0200, Jonas Smedegaard wrote:
>> Quoting Ole Streicher (2015-07-28 16:33:17)
>>> Ben Hutchings  writes:
 Installation of a package from the 'metapackages' section does 
 *not* mark its dependencies as automatically installed.
>>>
>>> Really? So, if someone would install a metapackage (for a test), and 
>>> then later uninstall it, its dependencies will remain on the system?
>>
>> That is my experience, yes.  Seems specific to metapackages, so I 
>> suspect there is some APT wizardry going on, treating those 
>> specially.
>
> Specifically, the APT::Never-MarkAuto-Sections configuration section 
> (in /etc/apt/apt.conf.d/01autoremove in a default install).

Quoting Paul Wise (2015-07-29 05:34:49)
> On Tue, Jul 28, 2015 at 11:22 PM, Jonas Smedegaard wrote:
>> Also, even for non-metapackages, if some other package just _suggest_ 
>> the package you pull in via depends/recommends, they stick as well.
>
> That is controlled by the middle one of these apt config settings:
>
> APT::Install-Recommends "false";
> APT::AutoRemove::SuggestsImportant "false";
> APT::AutoRemove::RecommendsImportant "false";

Thanks, Adam and Paul!

In case others like me prefer to explicitly mark wanted packages 
including kernels - as non-auto, here's my tweaks for that:

BEGIN 01autoremove--local
#clear APT::NeverAutoRemove;
#clear APT::VersionedKernelPackages;
#clear APT::Never-MarkAuto-Sections;
END

BEGIN 01autoremove-kernels-local
#clear APT::NeverAutoRemove;
END

BEGIN 99zz-local
APT::AutoRemove::SuggestsImportant "false";
END

Reason for the oddly named 01* files is to (hopefully¹) override 
immediately after unwanted declarations but not shadow e.g. 
01autoremove-postgresql deemed important to preserve.


 - Jonas

¹ I have not found documentation for nor tested if sorting order of 
inclusions is safe - just seemingly works for my da_DK locale.

-- 
 * 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: Metapackage dependencies: "Depends" or "Recommends"?

[Ole Streicher]

Neil Williams  writes:
> Ole Streicher  wrote:
>> There are no things "that the metapackage is for": The package just
>> collects a number of programs that belong to the same author and are
>
> The "same author" bit is a bit odd, there needs to be some common
> purpose in aggregating a list of packages into a metapackage in the
> first place but that's based on function, not authorship.

Ofcourse "same author" was a shortened explanation.

You may view "astromatic" as a toolbox, where it is handy to get the
whole toolbox at once. But there is no real need that the screwdriver is
in, or the hammer -- so if someone doesn't need something, he can just
remove it. Usually, one would install all tools together, but nothing
breaks if this is not the case.

But, the toolbox has no specific "function"; it is just handy since it
makes it easier for people to install what they want. "I want to have
the Astromatic packages" is a common user request.

>> usually installed together. There is no particular requirement to have
>> any of them installed; therefor I don't want to make any single
>> program as "Depend".
>
> I'd still use Depends in the metapackage. e.g. foo-server has lots of
> strict dependencies without which is simply won't install or start.

That is different. For me, my situation is comparable to the dependency
of Gnome from Evolution: I don't use Evolution at all, and I don't
understand why its binary must be installed on my Gnome desktop. I would
like to have it as a Recommends and then uninstall it (and I am not the
only one: you find some hack on how to remove on the internet). This is
IMO an ugly situation, which I want to avoid for my users.

Best regards

Ole



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/ytztwsnfkh2@news.ole.ath.cx

Re: Metapackage dependencies: "Depends" or "Recommends"?

[Andreas Tille]

On Tue, Jul 28, 2015 at 10:51:02AM -0700, Russ Allbery wrote:
> > I'm sure this is personal taste, and in the end it won't matter for most
> > people (except folks who don't install Recommends, but they're going to
> > break their system regardless),
> 
> I've had Recommends disabled for something like five years.  My systems
> have yet to break.  :)

And you did so because you are not a typical user of metapackages due to
your deep insight into the packaging system and things you need. 

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: https://lists.debian.org/20150729081348.gm16...@an3as.eu

Re: Metapackage dependencies: "Depends" or "Recommends"?

[Neil Williams]

On Tue, 28 Jul 2015 16:30:29 +0200
Ole Streicher  wrote:

> There are no things "that the metapackage is for": The package just
> collects a number of programs that belong to the same author and are

The "same author" bit is a bit odd, there needs to be some common
purpose in aggregating a list of packages into a metapackage in the
first place but that's based on function, not authorship.

> usually installed together. There is no particular requirement to have
> any of them installed; therefor I don't want to make any single
> program as "Depend".

I'd still use Depends in the metapackage. e.g. foo-server has lots of
strict dependencies without which is simply won't install or start.
foo-client has less dependencies and a few Recommends because the
client can work for a range of usecases and not everyone needs every
use case.

For those people who *do* want the assurance that every possible use
case can work, then a foo metapackage would Depend on foo-server and
foo-client and *all* of the Recommends of foo-client, possibly
including even a few of the Suggests of foo-client.
 
> Other packages will never depend on this metapackage; they will rather
> depend on the individual programs.
> 
> Or am I abusing the metapackage system here?

Different use cases, I think.

-- 


Neil Williams
=
http://www.linux.codehelp.co.uk/



pgpXD1efR2AVd.pgp
Description: OpenPGP digital signature

Re: Metapackage dependencies: "Depends" or "Recommends"?

[David Kalnischkies]

On Tue, Jul 28, 2015 at 05:22:35PM +0200, Jonas Smedegaard wrote:
> Quoting Ole Streicher (2015-07-28 16:33:17)
> > Ben Hutchings  writes:
> >> Installation of a package from the 'metapackages' section does *not*
> >> mark its dependencies as automatically installed.
> >
> > Really? So, if someone would install a metapackage (for a test), and 
> > then later uninstall it, its dependencies will remain on the system?
> 
> That is my experience, yes.  Seems specific to metapackages, so I 
> suspect there is some APT wizardry going on, treating those specially.

Currently yes, the keyword is as already noted in this thread
APT::Never-MarkAuto-Section, minus a bug in the handling, but I actually
intend to work on (read: remove/improve) this at DebCamp… all details
read best here: #793360

This is handled in the autoinstall part of MarkInstall in libapt, so
this only effects apt-based tools who rely on libapt doing the
dependency resolving for them (aka: basically everyone expect aptitude).
So whatever you observe with aptitude here is its own behaviour.


> Also, even for non-metapackages, if some other package just _suggest_
> the package you pull in via depends/recommends, they stick as well.

This is controlled by the APT::AutoRemove::SuggestsImportant option.
Set it to false if you must, but realize that this makes autoremove
a less save action as it removes features from a package (as the package
is hopefully not suggesting the other package for nothing, but to
provide an (obscure) feature you might or might not like to use).
Same just stronger for recommends of course.

This is handled by the autoremover (quelle surprise) in libapt, which
tags packages as garbage or not – and leaves it up to the frontend if
something is to be done with that information or not. So everyone is
using the same info, it just depends what is actually done with it.


> Both of above was not the case a few years ago...

I can answer that exactly with a bit of git blaming:
The first one was implemented by Michael Vogt eight years ago in apt
version 0.7.5, released on 25 Jul 2007.

The second was changed by me in apt version 0.8.15.3 from false to true,
released four years ago on 25 Jul 2011.

(I have no idea what it should tell you that the two releases are
exactly 4 years apart, but it makes me a bit unhappy that this thread
wasn't started 4 days earlier.)


Best regards

David Kalnischkies


signature.asc
Description: Digital signature

Re: Metapackage dependencies: "Depends" or "Recommends"?

[Paul Wise]

On Tue, Jul 28, 2015 at 11:22 PM, Jonas Smedegaard wrote:

> Also, even for non-metapackages, if some other package just _suggest_
> the package you pull in via depends/recommends, they stick as well.

That is controlled by the middle one of these apt config settings:

APT::Install-Recommends "false";
APT::AutoRemove::SuggestsImportant "false";
APT::AutoRemove::RecommendsImportant "false";

-- 
bye,
pabs

https://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
Archive: 
https://lists.debian.org/CAKTje6Eyv=pjsqeb457tzgeyle0iakezypbkepzpp3wk5r4...@mail.gmail.com

Re: Metapackage dependencies: "Depends" or "Recommends"?

[Adam D. Barratt]

On Tue, 2015-07-28 at 17:22 +0200, Jonas Smedegaard wrote:
> Quoting Ole Streicher (2015-07-28 16:33:17)
> > Ben Hutchings  writes:
> >> Installation of a package from the 'metapackages' section does *not*
> >> mark its dependencies as automatically installed.
> >
> > Really? So, if someone would install a metapackage (for a test), and 
> > then later uninstall it, its dependencies will remain on the system?
> 
> That is my experience, yes.  Seems specific to metapackages, so I 
> suspect there is some APT wizardry going on, treating those specially.

Specifically, the APT::Never-MarkAuto-Sections configuration section
(in /etc/apt/apt.conf.d/01autoremove in a default install).

Regards,

Adam


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1438106559.10045.2.ca...@adam-barratt.org.uk

Re: Metapackage dependencies: "Depends" or "Recommends"?

[Russ Allbery]

Paul Tagliamonte  writes:

> I'm sure this is personal taste, and in the end it won't matter for most
> people (except folks who don't install Recommends, but they're going to
> break their system regardless),

I've had Recommends disabled for something like five years.  My systems
have yet to break.  :)

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87oaiww4qh@hope.eyrie.org

Re: Metapackage dependencies: "Depends" or "Recommends"?

[KI7MT]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512


- From my dealings with Meta Packages in the past:

On 07/28/2015 09:22 AM, Jonas Smedegaard wrote:
> Quoting Ole Streicher (2015-07-28 16:33:17)
>> Ben Hutchings  writes:
>>> Installation of a package from the 'metapackages' section does *not*
>>> mark its dependencies as automatically installed.
>>
>> Really? So, if someone would install a metapackage (for a test), and 
>> then later uninstall it, its dependencies will remain on the system?

Removing the meta-package itself does not ( in most cases ) remove the
packages installed by the meta. It simply removes the meta-package itsel
f.

apt-cache depends, deborphan, autoremove and --purge are useful when
removing residuals from previously installed, and no longer needed, meta
packages. It's annoying that meta-packages do not remove what is
installed the same as it performs the installation if there are no deps
elsewhere.

You could also experiment with: aptitude unmarkauto
'?reverse-depends(PACKAG-NAME)' but I typically just use deborphen and
autoremove, or grab the packages from the control file and remove
manually, which is a Pain.
> 
> That is my experience, yes.  Seems specific to metapackages, so I 
> suspect there is some APT wizardry going on, treating those specially.
> 
> Also, even for non-metapackages, if some other package just _suggest_ 
> the package you pull in via depends/recommends, they stick as well.

Again, if the package does not have a dependency elsewhere, autoremove
"should" catch it and subsequently remove them.

> 
> 
> Both of above was not the case a few years ago...
> 
> 
>> Is there any simple way to remove them?
> 
> Not that I know of - would love to learn how!
> 
> 
>  - Jonas

best regards,

Greg

- 
Debian Hams..: https://alioth.debian.org/projects/pkg-hamradio/
Ubuntu Hams..: https://launchpad.net/~ubuntu-hams-devel
Launchpad: https://launchpad.net/~ki7mt
JTSDK: https://sourceforge.net/projects/jtsdk/
OpenPGP..: C177 6630 7115 78FE 9A2B 9F7F 18C0 F6B7 0DA2 F991

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBCgAGBQJVt6OlAAoJEBjA9rcNovmRhocP/3mReNuUkjqF9suXJn4+o3oM
o3OyrDvLV/8DFDfgQHQOGcTA2Jca+t9xezashrWmyTIaWjEGDTKLt46oQ/XaWGEe
KIfHCAjVTtTGvRbPoQBtlp8rSxIAA9dulNcr1MbmRNYzEkHt6YdASdC6IuJyWYbJ
0cYHVhPGSp+L48yiIx+ZCCOfi7/M8ZGdENmqV2QduoVCgRTqBPLbrD2BsLqOGAsY
2bOsUNwIdGN1KSZw8ksF8EfDZfqN5ptoIekH31TS1bMballcLdZPZ1jJbc0D83Pk
eiRK13M5Ge4wWsYcDy5nv0QpfB7+DTiZlYgdwUsWjWKukvRmrl7A9S/t2wmJ2mvk
2tYapR+pRndRHcP/DKKJsMM5vj+7LI8VhIt1ERrc5rvH0uabqUT6jPH61QC4zgSA
7fdq3TRsSaeIGtd0xETl7T2dhfGQO+24WbHlrLXiQGcwQg7dEF9vRemDDlskG5Hb
HuGAjCZFzP4J8Z5BbJosjeq0yByDOFFR6z5nhpZuUuzJ39APDwtIpp0ZtDQpyPkH
0gqjUBXVK8peChs2FV/spghAG96aulkfZAzChmNYZURz7hvQAGSYhFnYgbi9tHgf
uKbCHltENXngzouP+yd6YmrgO+vVaX9VwB4YU2BjQlkkGWbB/kyJM+eDdoU2z02d
zboijEYt5w4YSfrYGRCN
=9bG0
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/55b7a3a5.2010...@yahoo.com

Re: Metapackage dependencies: "Depends" or "Recommends"?

[Simon McVittie]

On 28/07/15 13:55, Paul Tagliamonte wrote:
> Well, I have a personal "thing" about this - it strikes me as quirky to
> not have a Depends, since those metapackages, without all of them, is
> technically not satisfied.
...
> I'd prefer to see metapackages use
> Recommends for the things that should (but don't *have* to be)
> installed, and Depends for the things that the metapackage is there
> for.

Consider a metapackage "games-fps" which pulls in openarena, nexuiz,
warsow and others, but does not have any particular reason to treat any
of them as mandatory; if you don't like OpenArena's visual style, for
instance, it's fine to deselect it, but if you have deselected *all* the
FPS games that were offered, then there's no point in having games-fps
at all.

Strictly speaking, from what you're saying, games-fps should have:

Depends: openarena | nexuiz | warsow | ...
Recommends: openarena, nexuiz, warsow, ...

because its purpose is to pull in 1 or more of those FPS games?

But actually implementing this would result in a lot of duplication (and
a more complex dependency graph), because there are really more than
three games offered; and there's no particular reason to list the games
in that order. So I think omitting the Depends and just taking the
Recommends is a reasonable simplification in cases like this one?

S


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/55b7a28f.5030...@debian.org

Re: Metapackage dependencies: "Depends" or "Recommends"?

[Jonas Smedegaard]

Quoting Ole Streicher (2015-07-28 16:33:17)
> Ben Hutchings  writes:
>> Installation of a package from the 'metapackages' section does *not*
>> mark its dependencies as automatically installed.
>
> Really? So, if someone would install a metapackage (for a test), and 
> then later uninstall it, its dependencies will remain on the system?

That is my experience, yes.  Seems specific to metapackages, so I 
suspect there is some APT wizardry going on, treating those specially.

Also, even for non-metapackages, if some other package just _suggest_ 
the package you pull in via depends/recommends, they stick as well.


Both of above was not the case a few years ago...


> Is there any simple way to remove them?

Not that I know of - would love to learn how!


 - 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: Metapackage dependencies: "Depends" or "Recommends"?

[Ole Streicher]

Ben Hutchings  writes:
> Installation of a package from the 'metapackages' section does *not*
> mark its dependencies as automatically installed.

Really? So, if someone would install a metapackage (for a test), and
then later uninstall it, its dependencies will remain on the system?

Is there any simple way to remove them?

Best regards

Ole


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/ytzy4i0fj2q@news.ole.ath.cx

Re: Metapackage dependencies: "Depends" or "Recommends"?

[Ole Streicher]

Paul Tagliamonte  writes:
> Well, I have a personal "thing" about this - it strikes me as quirky to
> not have a Depends, since those metapackages, without all of them, is
> technically not satisfied.

I don't understand this argument.

> I'd prefer to see metapackages use Recommends for the things that
> should (but don't *have* to be) installed, and Depends for the things
> that the metapackage is there for.

There are no things "that the metapackage is for": The package just
collects a number of programs that belong to the same author and are
usually installed together. There is no particular requirement to have
any of them installed; therefor I don't want to make any single program
as "Depend".

Other packages will never depend on this metapackage; they will rather
depend on the individual programs.

Or am I abusing the metapackage system here?

Best regards

Ole


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/ytz3808gxru@news.ole.ath.cx

Re: Metapackage dependencies: "Depends" or "Recommends"?

[Ole Streicher]

Simon McVittie  writes:
> On 28/07/15 13:08, Marvin Renich wrote:
>> There is no downside to using Recommends and no upside to using Depends
>> for metapackages.
>
> I don't think it's that simple; it comes down to a question of what the
> metapackage "means", which is a design question for its maintainer.
>
> For metapackages that are about getting a broad range of options, I
> think Recommends make sense, for the reasons you gave. I agree that
> games-finest is in this category: installing games-finest should pull in
> "a selection of outstanding Debian games", but if you don't like
> openarena and you remove it, you still have what it says in the
> package's Description.

My metapackages would fall into that category: They shall just provide a
structured view for the end user to other packages: They mean
f.e. "Install the packages from the 'astromatic' collection" -- it is no
mistake to review this list and unselect the package that are not needed.

So, I would still stick with Recommends.

Thank you,

Best regards

Ole


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/ytz7fpkgy4m@news.ole.ath.cx

Re: Metapackage dependencies: "Depends" or "Recommends"?

[Jonas Smedegaard]

Quoting Martin Read (2015-07-28 15:23:09)
> On 28/07/15 14:13, Ben Hutchings wrote:
>> Installation of a package from the 'metapackages' section does *not* 
>> mark its dependencies as automatically installed.
>
> This statement does not appear to be correct on my Debian jessie 
> system using aptitude. I just experimentally marked the cinnamon-core 
> package in the metapackages section "install this, please" in aptitude 
> (without hitting the "go" button), and the dependencies I didn't 
> already have installed are now showing in aptitude as "piA", not "pi".

Well, aptitude estimation do not reflect reality there:  Try actually 
performing the action and inspect the resulting system.

 - 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: Metapackage dependencies: "Depends" or "Recommends"?

[Martin Read]

On 28/07/15 14:13, Ben Hutchings wrote:

Installation of a package from the 'metapackages' section does *not*
mark its dependencies as automatically installed.


This statement does not appear to be correct on my Debian jessie system 
using aptitude. I just experimentally marked the cinnamon-core package 
in the metapackages section "install this, please" in aptitude (without 
hitting the "go" button), and the dependencies I didn't already have 
installed are now showing in aptitude as "piA", not "pi".



--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/55b7823d.1060...@zen.co.uk

Re: Metapackage dependencies: "Depends" or "Recommends"?

[Ben Hutchings]

On Tue, 2015-07-28 at 08:08 -0400, Marvin Renich wrote:
[...]
> If you use Depends, the user has two choices, install everything, or not
> use the metapackage.
> 
> Take the metapackage games-finest.  If all of those packages were
> Depends instead of Recommends, you could not remove a small handful of
> the larger games (e.g. wesnoth, at 153M) without marking every single
> game you wanted to keep as "manual" and then removing the metapackage.
> You then lose the ability to remove all of those games simply by
> removing the metapackage.
[...]

Installation of a package from the 'metapackages' section does *not*
mark its dependencies as automatically installed.

Ben.

-- 
Ben Hutchings
Hoare's Law of Large Problems:
Inside every large problem is a small problem struggling to get out.



signature.asc
Description: This is a digitally signed message part

Re: Metapackage dependencies: "Depends" or "Recommends"?

[Paul Tagliamonte]

On Tue, Jul 28, 2015 at 10:58:00AM +0200, Ole Streicher wrote:
> What is the rationale behind this? From the policy, I would think that
> "Recommends" is the perfect dependency here [2]:
> 
> | Recommends
> | 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.
> 
> Why should one use the much stronger "Depends" here?

Well, I have a personal "thing" about this - it strikes me as quirky to
not have a Depends, since those metapackages, without all of them, is
technically not satisfied.

I'm sure this is personal taste, and in the end it won't matter for
most people (except folks who don't install Recommends, but they're going to
break their system regardless), but I'd prefer to see metapackages use
Recommends for the things that should (but don't *have* to be)
installed, and Depends for the things that the metapackage is there for.


I am curious as to what consensus is on -devel

Cheers,
Paul

-- 
 .''`.  Paul Tagliamonte   |   Proud Debian Developer
: :'  : 4096R / 8F04 9AD8 2C92 066C 7352  D28A 7B58 5B30 807C 2A87
`. `'`  http://people.debian.org/~paultag
 `- http://people.debian.org/~paultag/conduct-statement.txt


signature.asc
Description: Digital signature

Re: Metapackage dependencies: "Depends" or "Recommends"?

[Simon McVittie]

On 28/07/15 13:08, Marvin Renich wrote:
> There is no downside to using Recommends and no upside to using Depends
> for metapackages.

I don't think it's that simple; it comes down to a question of what the
metapackage "means", which is a design question for its maintainer.

For metapackages that are about getting a broad range of options, I
think Recommends make sense, for the reasons you gave. I agree that
games-finest is in this category: installing games-finest should pull in
"a selection of outstanding Debian games", but if you don't like
openarena and you remove it, you still have what it says in the
package's Description.

For metapackages that exist to make upgrades work ("dummy packages"),
usually only Depends make sense: the package's entire purpose is to make
sure old dependencies pull in what's needed.

Tasks and task-like metapackages can be a mixture of both. It would make
no sense for xfce4 to drop its Depends on xfwm4 down to a Recommends: if
you don't have xfwm4, it is simply not true that you have "the core
packages of the Xfce4 desktop environment" and the package database
shouldn't claim that you do. Conversely, bumping xfce4's Recommends on
tango-icon-theme up to a Depends would seem excessive: installing xfce4
should normally give you its recommended icon theme, but if you choose
not to install that, the result is still xfce4. Similarly, d-i tasks are
careful to distinguish between Depends and Recommends.

Perhaps the right question to be asking is: if foo has a RC bug, does
that inherently make the task-bar metapackage unreleasable? If yes, then
task-bar Depends on foo; if no, then task-bar Recommends (or even
Suggests) foo.

Applying that logic to the xfce4 metapackage: if xfwm4 had a RC bug and
got kicked out of testing, then the XFCE suite would not be not usable,
so we should also consider xfce4 to be RC-buggy. Good; it should have a
Depends, which it does. If tango-icon-theme had a RC bug and got kicked
out of testing, then the XFCE suite would only be superficially
different under some other icon theme (perhaps hicolor or gnome), so
xfce4 should not be considered to be RC-buggy. Also good: it should have
a Recommends or weaker, and indeed it does.

Applying the same idea to the games metapackages, if openarena becomes
RC-buggy and gets kicked out of testing, then games-finest and games-fps
have lost one of their games; but they still have others, so they still
serve their purpose, and aren't RC-buggy.

S


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/55b77b90.6090...@debian.org

Re: Metapackage dependencies: "Depends" or "Recommends"?

[Marvin Renich]

* Ole Streicher  [150728 05:15]:
> Hi,
> 
> I recently created two metapackages (astromatic and eso-pipelines) which
> were accepted by the ftp-masters yesterday. However, I got a commend
> that my choice of "Recommends" dependencies is discouraged:
> 
> Paul Richards Tagliamonte  [1]:
> > using Recomends and not Depends on the metapackage strikes me as very
> > awkward. I think I get what you're trying to do (allow folks to remove
> > one package they don't want, I guess), but I really don't think that's
> > quite right.
> 
> What is the rationale behind this? From the policy, I would think that
> "Recommends" is the perfect dependency here [2]:
> 
> | Recommends
> | 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.
> 
> Why should one use the much stronger "Depends" here?

I strongly believe Recommends is correct.  First, this is clearly what
the policy states.  Second, it allows you to use the package manager the
way it was intended (which is the reason for the definition in policy).

If you use Recommends, you put the user in control of what is on his/her
system.  You can install the whole metapackage, or just the parts you
want, but still have the whole thing removed by removing the
metapackage.

If you use Depends, the user has two choices, install everything, or not
use the metapackage.

Take the metapackage games-finest.  If all of those packages were
Depends instead of Recommends, you could not remove a small handful of
the larger games (e.g. wesnoth, at 153M) without marking every single
game you wanted to keep as "manual" and then removing the metapackage.
You then lose the ability to remove all of those games simply by
removing the metapackage.

There is no downside to using Recommends and no upside to using Depends
for metapackages.  I believe that policy should explicitly mention
Recommends as the correct dependency for metapackages.

A metapackage should not be a hammer to beat the user into installing
everything you want them to, it should be a tool to allow the user to
easily select a group of related packages that make sense to install
together.  Any real Depends relationship should be specified in the
sub-packages.  Note that games-finest Depends on games-tasks; this is an
example of correct use of Depends in a metapackage.

...Marvin


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150728120833.gg21...@basil.wdw

Metapackage dependencies: "Depends" or "Recommends"?

[Ole Streicher]

Hi,

I recently created two metapackages (astromatic and eso-pipelines) which
were accepted by the ftp-masters yesterday. However, I got a commend
that my choice of "Recommends" dependencies is discouraged:

Paul Richards Tagliamonte  [1]:
> using Recomends and not Depends on the metapackage strikes me as very
> awkward. I think I get what you're trying to do (allow folks to remove
> one package they don't want, I guess), but I really don't think that's
> quite right.

What is the rationale behind this? From the policy, I would think that
"Recommends" is the perfect dependency here [2]:

| Recommends
| 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.

Why should one use the much stronger "Depends" here?

Best regards

Ole

[1] 
http://lists.alioth.debian.org/pipermail/debian-astro-maintainers/Week-of-Mon-20150727/001597.html
[2] https://www.debian.org/doc/debian-policy/ch-relationships.html


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/ytzbnewhd5z@news.ole.ath.cx