Metapackage dependencies: "Depends" or "Recommends"?

classic Classic list List threaded Threaded
38 messages Options
12
Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]> [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 [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: https://lists.debian.org/ytzbnewhd5z.fsf@...

Reply | Threaded
Open this post in threaded view
|

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

Marvin Renich
* Ole Streicher <[hidden email]> [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 <[hidden email]> [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 [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: https://lists.debian.org/20150728120833.GG21533@...

Reply | Threaded
Open this post in threaded view
|

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

Simon McVittie-7
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 [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: https://lists.debian.org/55B77B90.6090904@...

Reply | Threaded
Open this post in threaded view
|

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

Paul Tagliamonte-3
In reply to this post by Ole Streicher
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 <[hidden email]>  |   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 (968 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Ben Hutchings-3
In reply to this post by Marvin Renich
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 (828 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Martin Read-2
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 [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: https://lists.debian.org/55B7823D.1060400@...

Reply | Threaded
Open this post in threaded view
|

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 (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Ole Streicher
In reply to this post by Simon McVittie-7
Simon McVittie <[hidden email]> 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 [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: https://lists.debian.org/ytz7fpkgy4m.fsf@...

Reply | Threaded
Open this post in threaded view
|

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

Ole Streicher
In reply to this post by Paul Tagliamonte-3
Paul Tagliamonte <[hidden email]> 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 [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: https://lists.debian.org/ytz3808gxru.fsf@...

Reply | Threaded
Open this post in threaded view
|

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

Ole Streicher
In reply to this post by Ben Hutchings-3
Ben Hutchings <[hidden email]> 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 [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: https://lists.debian.org/ytzy4i0fj2q.fsf@...

Reply | Threaded
Open this post in threaded view
|

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

Jonas Smedegaard
Quoting Ole Streicher (2015-07-28 16:33:17)
> Ben Hutchings <[hidden email]> 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 (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Simon McVittie-7
In reply to this post by Paul Tagliamonte-3
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 [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: https://lists.debian.org/55B7A28F.5030901@...

Reply | Threaded
Open this post in threaded view
|

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

KI7MT
In reply to this post by Jonas Smedegaard
-----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 <[hidden email]> 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 [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: https://lists.debian.org/55B7A3A5.2010403@...

Reply | Threaded
Open this post in threaded view
|

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

Russ Allbery-2
In reply to this post by Paul Tagliamonte-3
Paul Tagliamonte <[hidden email]> 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 ([hidden email])               <http://www.eyrie.org/~eagle/>


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: https://lists.debian.org/87oaiww4qh.fsf@...

Reply | Threaded
Open this post in threaded view
|

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

Adam D. Barratt
In reply to this post by Jonas Smedegaard
On Tue, 2015-07-28 at 17:22 +0200, Jonas Smedegaard wrote:

> Quoting Ole Streicher (2015-07-28 16:33:17)
> > Ben Hutchings <[hidden email]> 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 [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: https://lists.debian.org/1438106559.10045.2.camel@...

Reply | Threaded
Open this post in threaded view
|

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

Paul Wise via nm
In reply to this post by Jonas Smedegaard
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 [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: https://lists.debian.org/CAKTje6Eyv=pjSQeb457TzgeyLe0iaKeZYpbkePzPp3WK5r485w@...

Reply | Threaded
Open this post in threaded view
|

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

David Kalnischkies-4
In reply to this post by Jonas Smedegaard
On Tue, Jul 28, 2015 at 05:22:35PM +0200, Jonas Smedegaard wrote:

> Quoting Ole Streicher (2015-07-28 16:33:17)
> > Ben Hutchings <[hidden email]> 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 (817 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Neil Williams-4
In reply to this post by Ole Streicher
On Tue, 28 Jul 2015 16:30:29 +0200
Ole Streicher <[hidden email]> 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/


attachment0 (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Andreas Tille-5
In reply to this post by Russ Allbery-2
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 [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: https://lists.debian.org/20150729081348.GM16259@...

Reply | Threaded
Open this post in threaded view
|

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

Ole Streicher
In reply to this post by Neil Williams-4
Neil Williams <[hidden email]> writes:
> Ole Streicher <[hidden email]> 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 [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: https://lists.debian.org/ytztwsnfkh2.fsf@...

12