On Wed, Jul 11, 2012 at 08:51:32AM -0300, Henrique de Moraes Holschuh wrote:
> Broken as in "partially working because there are expected features missing"
> is the _very_ definition of "not installing a recommended package".
>
> Now, "broken" as in "doesn't work at all for any use case" would be a bug,
> yes.
I don't disagree with you, and I think that this largely boils down to
expectations management. "Doesn't work at all" is easier to define and agree
upon than "doesn't work as I expected", and I think maintainers have
widely-differing interpretations of how to use Recommends: as a result.
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: http://lists.debian.org/20120711125013.GB11211@debian
07-11-2012, 01:05 PM
Thibaut Paumard
Recommends for metapackages
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hi,
Le 11/07/12 14:36, Gergely Nagy a écrit :
> Henrique de Moraes Holschuh <hmh@debian.org> writes:
>
>> IMO, metapackages should "depend" on the absolutely required
>> stuff (and many times that will be the empty set), "recommend"
>> the rest, and maybe even "suggest" fringe packages. This
>> achieves maximum usability for more usecases, and malfunctions
>> only in the unsupported case of "no install recommends by
>> default" -- you should skip recommends always in a case-by-case
>> basis.
>
Of course, there could be a "network-manager-gui" virtual package so
that gnome-core can depend on "network-manager-gui |
network-manager-gnome".
By the way, I find it enlightening to realize that "gnome" only
recommends network-manager-gnome whereas gnome-core depends on it.
> That also achives maximum annoyance, because if I want the full
> platform, I'll have to go recommends/suggest hunting. (No, I'm
> *not* going to turn on install-recommends.)
You don't want to turn on install-recommends, but you are happy with
installing a loaded meta-package such as "gnome" or "kde-full"? I very
much don't see the rationale behind this. This is what policy has to
say about "Recommends":
"The Recommends field should list packages that would be found
together with this one in all but unusual installations."
>> OTOH, metapackages from hell (like gnome or kde-full) based on
>> Depends require me to select them, go to the "will install these"
>> screen, deselect the meta package, and go over the list manually
>> installing whatever isn't going to be useless/unwelcome for my
>> specific case. And I will never notice if the metapackage
>> changes its dependency tree later on.
>
> You could script all that, and keep your local list up-to-date
> with about ~10 minutes of work.
The annoyance of not being able to uninstall just one of many packages
pulled by a big meta-package does not affect only developers. A
reasonable solution should be found which works for our priority: our
users.
Regards, Thibaut.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4FFD7A20.2030203@users.sourceforge.net">http://lists.debian.org/4FFD7A20.2030203@users.sourceforge.net
>> That also achives maximum annoyance, because if I want the full
>> platform, I'll have to go recommends/suggest hunting. (No, I'm
>> *not* going to turn on install-recommends.)
>
> You don't want to turn on install-recommends, but you are happy with
> installing a loaded meta-package such as "gnome" or "kde-full"?
I am happy with installing gnome, because I (or my parents, in case of
my desktop) use pretty much all of it from time to time.
Would I find something in it that I never use, and would it eat enough
space or other resources to annoy me, I'd do my own local meta-package
instead, that wouldn't have the unnecessary parts.
The reason I do not turn on install-recommends, is because in the vast
majority of cases, I do not need the recommended packages. Removing them
by hand is much more work than installing the few that I do need. This
isn't the case for the gnome meta-package.
As for kde-full: no, I'd never install it. There's one kde thing I use,
kcachegrind, and I'm happy to install that by hand. Would I be a kde
user, I would probably not install kde-full either, because - by the
looks of it - there would be significant parts of it that I'll never
use. That doesn't mean it should only recommend them, no need to, I'm
perfectly capable of installing the subset I need.
I am also perfectly capable of writing a script to notify me whenever
the meta-package's dependencys change, so I will have the option to pull
in new things if I want to. (Said script is ~10 lines, and I wrote it
yesterday in about 5 minutes; less time than I spent replying to this
mail.)
>>> OTOH, metapackages from hell (like gnome or kde-full) based on
>>> Depends require me to select them, go to the "will install these"
>>> screen, deselect the meta package, and go over the list manually
>>> installing whatever isn't going to be useless/unwelcome for my
>>> specific case. And I will never notice if the metapackage
>>> changes its dependency tree later on.
>>
>> You could script all that, and keep your local list up-to-date
>> with about ~10 minutes of work.
>
> The annoyance of not being able to uninstall just one of many packages
> pulled by a big meta-package does not affect only developers. A
> reasonable solution should be found which works for our priority: our
> users.
Like I said earlier: script it. I posted a script that can remove any
number of packages from another's depends line, and echo a control
file. Updating that to create a local meta-package is a piece of
cake. Hooking it into apt is also similarly easy, and bingo, you have a
solution.
Package it up, create a config file for it, and it's ready to be shipped
to users. Everyone wins.
The whole thing is about an hour of work with everything included for
anyone who cares enough, far less than the time already spent arguing
about silly things on this list.
--
|8]
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: http://lists.debian.org/87fw8ywhyf.fsf@algernon.balabit
07-11-2012, 03:30 PM
"Eugene V. Lyubimkin"
Recommends for metapackages
On 2012-07-11 14:33, Gergely Nagy wrote:
> "Eugene V. Lyubimkin" <jackyf@debian.org> writes:
>
> > Moreover, despite me understanding the picture, I still
> > has no clean, safe and documented way to do what I'd want in case the
> > package maintainer chosed Depends.
>
> You have: install the pieces you want by hand. That's at least clean and
> safe. I do not think it is worth documenting explicitly.
No, this is (IMO) not a solution: [1]
> >> > Using Recommends for non-core parts of
> >> > metapackages' dependencies would nicely solve that.
> >>
> >> ...but I disagree that making meta-packages more elastic is a "nice"
> >> solution: is a hack covering over misguided users. Possible solutions
> >> could be improved documentation and improved design of package managers.
> >
> > ... And I disagree with that. No solution can override policy's "all
> > Depends must be satisfied". If one choose to support the "exclude from
> > metapackage" one either has to change the policy, remove packages from
> > Depends or use non-stock metapackage (which I personally don't like).
>
> [...] Demoting to Recommends would be
> less so, but if upstream considers a package a core part of a platform,
> recommends *is* wrong. If you disagree with upstream, you have the tools
> and the ability to customize your system: use a non-stock meta package.
Well, disagreed here. By the logic above we, for example, cannot apply
any patches NACKed by upstream.
> It's not hard. I'd be very curious why you're so against it, perhaps we
> can come up with a solution that satisfies you?
Because if a user who installed Debian yesterday asks me "So how do I do
that?" I want my answer to be
"It's easy, just do '$packagemanager remove $singlepackage'"
instead of
"It's easy, just build and maintain a non-stock meta package"
[1] a) and b) here: https://lists.debian.org/debian-devel/2012/07/msg00237.html
--
Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com
C++ GNU/Linux developer, Debian Developer
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: http://lists.debian.org/20120711153006.GB7554@r500-debian
07-11-2012, 03:38 PM
Fabian Greffrath
Recommends for metapackages
By the way, I find it enlightening to realize that "gnome" only
recommends network-manager-gnome whereas gnome-core depends on it.
That was at gnome 2.30 times...
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4FFD9DE1.2060000@greffrath.com">http://lists.debian.org/4FFD9DE1.2060000@greffrath.com
07-11-2012, 05:54 PM
Abou Al Montacir
Recommends for metapackages
On Tue, 2012-07-10 at 20:01 +0200, Jonas Smedegaard wrote:
> On 12-07-10 at 06:34pm, Abou Al Montacir wrote:
> > On Tue, 2012-07-10 at 18:10 +0200, Jonas Smedegaard wrote:
> > > The very purpose of a meta-package is to _ensure_ that a certain set
> > > of packages is installed, not just recommend them: All (not only
> > > most) users of that package need all its dependencies satisfied -
> > > those that don't should simply uninstall the meta-package.
> >
> > Exactly! And as confirmation see below you will see gnome recommending
> > and even suggesting, which is probably fine:
>
> [lots of more or less unrelated package dependencies snipped]
>
> > The most logical is that gnome-core does not depend on
> > network-manager-gnome but the gnome package do. Indeed, experienced
> > users will install gnome-core and select the rest manually.
>
> I disagree: Looking at the many other dependencies of gnome-core, it
> clearly isn't meant as "smallest possible GNOME setup" but more
I never said that, I'm looking for a gnome installation with most of
functionalities. I'm not interested in all functionalities. I'm not a
Linux newbe but not also a gnome expert which knows what should be
installed and what not. Typical use case is system administrator who
have configured network using ifup/ifdown, needs to provide a working
gnome for hist 1000 users, without having to figure out what they need
and what they don't need.
He don't want to learn how to use NM as his network configuration is
working for more than 10 years.
> "essential parts of what the upstream GNOME project has to offer" - as
> its package description also clearly reflects.
And NM is not essential in my point of view even if I don't see how I
can do on my laptop without it and even if I love this package when I'm
switching from WIFI access point to another, I find it absolutely not
useful on a workstation with static IP and NFS (freezing the system each
time NM tries to handle the connection).
> When I want "smallest possible GNOME setup" i install gnome-session
As said before, I'm not looking for a minimal gnome, but for a typical
gnome installation.
I think this could be solved by relaxing dependency on gnome-core using
a new gnome-laptop package which depends on NM even if I think that this
is not mandatory:
You just need to make
gnome-core recommends gnome-network-manger
gnome depends on gnome-network-manager
I can argue that a network connection is not part of the core
functionality as gnome could work perfectly without network connection.
Cheers,
07-11-2012, 06:17 PM
Noel David Torres Taño
Recommends for metapackages
> Some argue that meta-packages can have a different purpose, and some
> argue that recommending also to some (lesser) extend ensures
> installation of packages. None of that, however, changes the fact that
> _this_ meta-package _now_ has the feature of strictly ensuring a certain
> set of packages. For those wanting that. And not for those feeling it
> is in their way, but those can simply avoid that package: A meta-package
> has no functionalirty beyond pulling in packages, so there is no loss to
> the resulting system other than lack of its sole feature.
*
Error. A meta-package has functionality way beyond that. It exists not only to pull in packages, but also to allow auto removal of leaf packages when the admin decides to get rid of them, to maintain a collection of related packages together, to avoid deinstallations when upgrading libraries (aptitude has the insane actitude of proposing removal of tons of packages before proposing upgrading une of them, and if you see your loved metapackage in the list you know something is wrong with the option and press . ), pulling new software in when the collection changes, etc.
*
So a meta-package is "just" a way of installing things together, and a lot more. But from those things, only dependencies should be Depends, and software that improves the collection should be Recommends. In this particular case, N-M improves gnome but it is not needed at all.
*
Think on this use case: a user wants a full gnome installation and to be able to get new versions of programs (or even new substitute programs) to be automatically installed when they change on the 'gnome' package, but also wants pidgin and evolution work online while he has a static interface (not managed by n-m). This user can fill a bug against gnome-core due that it forces him to install a package that breaks the functionality of pidgin on his system.
*
And he is right.
*
Regards
Noel Torres
er Envite
07-11-2012, 06:21 PM
Noel David Torres Taño
Recommends for metapackages
> I still (as previously mentioned) believe that you really should focus
> on gnome-session instead, if you feel gnome-core is too invasive when it
> insist on installing certain image viewer, web browser, video player and
> "other tools" (which includes a certain network manager).
>
Installing an image viewer, a web browser or a video player does not break functionality of unrelated software, just gives you more options.
*
Installing N-M breaks unrelated software.
*
Regards
*
Noel Torres
er Envite
07-11-2012, 06:31 PM
Noel David Torres Taño
Recommends for metapackages
> Yet, we try to not diverge much from upstream, and maintain a good
> relationship with them. If they consider it core, so can we. Those who
> want to hand-pick parts of a meta package, can do so, we do not forbid.
*
If we want to be user friendly, it is not a matter of "we do not forbid", it is a matter of "we make easy". Besides, low-level users will install Recommends by default, so they will get the whole box anyway. But medium or high level users may probably want N-M not to mess their network EVEN if they want the whole gnome desktop set.
>
> I do not see the problem: those who want the full platform, can get it
> easily. Those who don't, and want to exclude some, they can do so easily
> too. A bit more work, but hey, if you're going to cherry pick, that will
> always involve more work.
>
> The amount of extra work necessary is minimal though.
*
Not so minimal if you want your gnome set to be up to date, including new applications being installed.
*
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. If that package is not a true dependency of the core of the set, Recommends is more than justified.
*
Regards
Noel Torres
er Envite
07-11-2012, 06:31 PM
Henrique de Moraes Holschuh
Recommends for metapackages
On Wed, 11 Jul 2012, Gergely Nagy wrote:
> Henrique de Moraes Holschuh <hmh@debian.org> writes:
> > IMO, metapackages should "depend" on the absolutely required stuff (and many
> > times that will be the empty set), "recommend" the rest, and maybe even
> > "suggest" fringe packages. This achieves maximum usability for more
> > usecases, and malfunctions only in the unsupported case of "no install
> > recommends by default" -- you should skip recommends always in a
> > case-by-case basis.
>
> That also achives maximum annoyance, because if I want the full
> platform, I'll have to go recommends/suggest hunting. (No, I'm *not*
> going to turn on install-recommends.)
You're not using the recommended behaviour which exists for extremely good
reasons (_and_ it is the default almost every user will use, mandated and
backed by policy for years). That gives you the extra responsibility of not
missing any "recommended" package that you should have installed.
I am extremely unimpressed. While I commend you in being one of the guinea
pigs that will be hit first when someone misclassifies a dependency as
"recommends" instead of "depends" and I recognize the importance of that
job, I fell that is hardly a good reason to push against better metapackages
that would make them actually useful for a much larger set of people[1].
I routinely skip installing recommended packages, but I take that decision
in a case-by-case basis. Unlike you, I am not pushing on the majority an
inferior, sub-optimal behaviour which I'd not be willing to deal with
myself. I *already* deal with the resulting sub-optimal behaviour of
metapackages abusing "depends".
[1] As in people complaining in debian-user that: "<package manager> wants
to remove my entire desktop environment" when the user tries to install a
package that "conflicts" with something "depended" by a metapackage.
> > OTOH, metapackages from hell (like gnome or kde-full) based on Depends
> > require me to select them, go to the "will install these" screen, deselect
> > the meta package, and go over the list manually installing whatever isn't
> > going to be useless/unwelcome for my specific case. And I will never notice
> > if the metapackage changes its dependency tree later on.
>
> You could script all that, and keep your local list up-to-date with
> about ~10 minutes of work.
So could you. The difference is that you'd be doing it because you're
running with your package manager configured for behaviour opposite to the
recommended one that all regular users and most DDs do.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120711183131.GE4847@khazad-dum.debian.net">http://lists.debian.org/20120711183131.GE4847@khazad-dum.debian.net
Recommends for metapackages
