FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Development

 
 
LinkBack Thread Tools
 
Old 07-13-2012, 05:27 AM
Tollef Fog Heen
 
Default Recommends for metapackages

]] Gergely Nagy

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

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

--
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87zk74i628.fsf@xoog.err.no">http://lists.debian.org/87zk74i628.fsf@xoog.err.no
 
Old 07-13-2012, 06:17 AM
Gergely Nagy
 
Default Recommends for metapackages

Wouter Verhelst <wouter@debian.org> writes:

> On Tue, Jul 10, 2012 at 04:18:17PM +0200, Gergely Nagy wrote:
>> "Eugene V. Lyubimkin" <jackyf@debian.org> writes:
>>
>> > On 2012-07-10 15:32, Josselin Mouette wrote:
>> >> Le mardi 10 juillet 2012 à 17:38 +0900, Miles Bader a écrit :
>> >> > What's wrong with Recommends: in that case? It seems to perfectly
>> >> > match the "makes life easier for <common but not universal use-case
>> >> > XXX>" scenario you describe.
>> >>
>> >> Recommends is wrong for metapackages because it gets upgrades very
>> >> wrong. This is why it is used very marginally.
>> >
>> > Standards should not depend on implementation details. I see zero
>> > reasons why metapackages are (or should be) specific here. Whatever $it
>> > that gets upgrades wrong should be fixed instead.
>>
>> But the purpose of the meta-package is to pull stuff in. Depends does
>> that, Recommends does not, therefore Recommends is not appropriate for
>> the task.
>
> Of course it does. Five years ago, when apt didn't install recommends by
> default, recommends might not have been appropriate, but these days it
> is.

Does it pull in recommends on upgrade? No? Just how useful are they
then, for following the changes in the meta?

Does Recommends guarantee that the platform will stay intact, unless I
explicitly remove a recommended package? No? That'll be fun! "I
installed gnome, but an upgrade wants to remove totem! What's up with
that??" Is no better than "I installed gnome, but an upgrade wants to
remove it altogether", except the former is more dangerous, as it wants
to remove a package you didn't install by hand, and may not know what it
does. For novice users, the former is far more dangerous, because they
may not know what the removed package is for. At least with Depends, the
same upgrade would want to remove the Gnome metapackage, and they'd know
what THAT is, and can stop the upgrade.

No, recommends are a terrible idea for meta-packages.

--
|8], who still doesn't like being CC'd on list mail.


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87a9z4tcbd.fsf@luthien.mhp">http://lists.debian.org/87a9z4tcbd.fsf@luthien.mhp
 
Old 07-13-2012, 06:19 AM
Gergely Nagy
 
Default Recommends for metapackages

Tollef Fog Heen <tfheen@err.no> writes:

> ]] Gergely Nagy
>
>> Instead of fighting for Recommends, which would break your system in
>> various interesting ways later on[1], there's a third solution: noone
>> stops anyone from uploading a gnome-minimal package, which depends on
>> gnome-session and a few selected other parts, without n-m.
>
> I would think it quite rude to trample on the gnome-* namespace unless
> this is well coordinated with the GNOME packagers. If they're happy
> with it, that's a different situation.

I agree. But from what I've seen so far, it seems to me that it would be
far easier to persuade the relevant people to accept a new meta, than to
downgrade anything to Recommends.

(Also a much better idea than Recommends

--
|8]


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87629stc7k.fsf@luthien.mhp">http://lists.debian.org/87629stc7k.fsf@luthien.mhp
 
Old 07-13-2012, 06:33 AM
Gergely Nagy
 
Default Recommends for metapackages

Andrei POPESCU <andreimpopescu@gmail.com> writes:

> On Jo, 12 iul 12, 15:46:05, Gergely Nagy wrote:
>>
>> X) Downgrade stuff to recommends
>> ================================
>>
>> I do not consider this a solution, for reasons explained elsewhere,
>> where my main concern is that it breaks the assumption that installing a
>> platform (in this case, gnome) will install the whole thing, and it will
>> be available for my use at any time.
>
> Well, it will, in all but unusual installations

No. See below.

>> With recommends, there's a fair chance that a distinctly related package
>> forces part of the platform off, and the package manager will happily
>> remove them. Once the breakage is fixed, it will not reinstall them.
>
> Could you please elaborate on that? The only thing I can think of that
> would force some packages to not be installed (or removed) is a
> Conflicts (or unsatisfiable Depends, but this shouldn't happen in
> stable).

As far as stable is concerned, a conflict, yes. For unstable, where
package releations are more interesting, unsatisfiable Depends too.

> With Recommends you get a simple prompt that a specific package will be
> uninstalled and comparing the descriptions will probably give a hint to
> any user that those packages might conflict (assuming they don't look at
> the Conflicts).

So, on each upgrade, the user would need to:

- Double guess the system, to not botch an upgrade
- Read N number of package descriptions to figure out wtf that thing it
wants to remove is.

How is that user friendly and good?

> With Depends aptitude will suddenly want to remove a whole bunch of
> packages (that may or may not look related) and apt-get will suggest you
> to do this via autoremove. Then you have go hunting with apt-mark,
> yay!

With Depends, I will instantly know something is botched. With
recommends, it will happily remove half the platform unless I stop it
manually. Which I most likely wont, as I'm doing unattended
upgrades. And I do unattended upgrades, because I trust the system to do
the right thing, and not remove stuff from under me that it should not.

I *hate* doing things manually, that's why I'm using a bloody high-level
package manager. If it forces me to double-guess it, check a lot of
things during upgrades, I might aswell go back to downloading packages
by hand and using dpkg directly myself.

>> This can be worked around by removing the auto-installed flag from those
>> parts of the platform that I want to keep at all times, but then what is
>> the use of Recommends, when I have to cherry pick anyway? I could just
>> skip installing the meta, the net effect is the same (except, that
>> without the meta, there are no expectations to break).
>
> Are you talking about testing or sid?

Either.

>> I still don't see the problem with installing a subset by hand. Advanced
>> users can script it, novices will only need to hand pick once. Done. 10
>> minutes job.
>
> IMO the main problem is:
>
> # aptitude remove package
> Following packages will be removed:
> [Big list with 100+ packages]

How is that better than:

# aptitude upgrade
Following packages will be removed:
[A list of 10+ packages you have no clue about]

A novice user will answer no to the former, and keep his system
intact. He will answer yes to the latter, because he never heard of
those packages before, and trusts the package manager to do the right
thing.

Hi, you have a broken system.

But, it can also happen when you remove a dependency of a recommended
package:

# aptitude remove dependency-of-a-recommended-package
[ List of 10+ packages you have no clue about ]

There goes your video player, your audio player and probably a bunch of
other things.

Unless the user double-checks what those 10+ packages are, which most
likely he won't.

>> Compare that to the hours wasted trying to figure out what forced part
>> of the platform off my system and when, during an unattended
>> upgrade.. Yes, I do those, because I want to trust the system doing the
>> right thing, and keeping stuff I installed intact and complete.
>
> Sorry, I thought we were talking about stable, why would something like
> that happen.

If we're talking about stable only, there's even less reason for
Recommends.

--
|8]


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87y5morx0a.fsf@luthien.mhp">http://lists.debian.org/87y5morx0a.fsf@luthien.mhp
 
Old 07-13-2012, 06:36 AM
Gergely Nagy
 
Default Recommends for metapackages

Andrei POPESCU <andreimpopescu@gmail.com> writes:

> On Jo, 12 iul 12, 12:10:29, Gergely Nagy wrote:
>>
>> Erm, how have I broken my system? I did not. (Turning Install-Recommends
>> off is definitely not breaking my system, FYI.)
>
> It means you are running with a non-default configuration and you should
> be aware of the side-effects.

I am aware of side-effects, thank you. I turn it off because of the
side-effects. That does not make my system broken, however.

> Please don't forget that a Recommends will pull in packages in all but
> unusual installations

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

I do not think upgrade is an unusual situation, fwiw. For stable, it is,
for everything else, not so much. But half the arguments for Recommends
(with regards to meta-packages) are invalid for stable anyway.

The only valid argument for stable is that apt-get remove gnome will
want to remove a whole bunch of stuff. My counter argument is that doing
so is safer than screwing up the user's system.

--
|8]


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87txxcrwu3.fsf@luthien.mhp">http://lists.debian.org/87txxcrwu3.fsf@luthien.mhp
 
Old 07-13-2012, 07:05 AM
Gergely Nagy
 
Default Recommends for metapackages

Andrei POPESCU <andreimpopescu@gmail.com> writes:

> On Jo, 12 iul 12, 17:44:52, Gergely Nagy wrote:
>>
>> > Then some time later during upgrade it'll upgrade all packages
>> > but will not install N-M; at the same time it'll install
>> > new package that was added to Recommends in that new version.
>>
>> As far as I remember, it will not install new recommends.
>
> http://lists.debian.org/CAAZ6_fDTAydt1UBp08yf0d8L0JUSFFY1rZYHVmvztFCjeOcEw g@mail.gmail.com

Hmm, right. dist-upgrade will pull new recommends in, indeed. Well,
there goes one argument against Recommends. The rest still stands,
though.

>> But, the problem I'm talking about is not related to this. The problem I
>> see is when I have a gnome meta-package, that recommends, say,
>> totem. Now, lets suppose I'm also running unstable, for one reason or
>> the other, and a transition comes along, and something has a breaks on
>> stuff totem depends on, and the package manager decides to remove totem.
>>
>> Weeks later, when I want to watch a movie, at the end of the world, with
>> no network connectivify, I realize that something pulled my movie player
>> out of me.
>>
>> I would be very, very sad.
>>
>> Of course, silly me, why do I run unstable? And why don't I pay
>> attention to what my upgrades do? Well, I run unstable because I work
>> with it, and it has up-to-date stuff I have to work with. And running
>> unstable is far easier than running testing and cherry-picking (did I
>> mention I hate manual bookkeeping?). I do unattended upgrades, because I
>> trust the system to keep everything I installed, installed. I installed
>> the gnome meta-package because I want the full thing, bells, whistles
>> and crap included.
>
> Sorry, but IMNSHO running sid with unattended upgrades just asks for
> trouble. But then again IANADD, if Debian wants to optimize for this use
> case who am I to disagree?

Similar issues can happen in stable, less often, and for different
reasons, but the possibility still exists.

Also - and this easily happens in stable too -, there's the problem of
trying to remove a dependency of a recommended package.

That will happily remove the recommended package, and keep the meta. A
user may or may not know what those strangely named packages that get
removed are, and making him look it up, and watch every upgrade like a
hawk isn't exactly friendly.

>> I could, of course, mark totem manually installed, but then I'm back to
>> manual bookkeeping, could've installed the whole stuff by cherry-picking
>> each component, and that makes the meta-package useless for me, and
>> destroys the argument that recommends would result in less bookkeeping.
>>
>> Thus, here's an example where Recommends *will break* an existing
>> system.
>>
>> Oh, and since apt won't install new recommends on upgrade, to the best
>> of my knowledge, I won't get totem back once the
>> transition/breakage/whatever is fixed, either. While if it would be a
>> dependency, the upgrade would abort, because it'd try to remove a
>> package marked as manually installed.
>>
>> But similarly, if I ran stable, and one of the meta packages I installed
>> had a recommends on a piece of software, and I try to install something
>> that conflicts with it (either directly, or indirectly, via another meta
>> package, for example), then this piece of software gets removed. I may
>> or may not notice that - I might not even know wtf totem is, a novice
>> user who first sees Linux certainly won't - so it gets removed.
>
> Well, if the purpose of the Depends are to protect a novice from
> removing packages by mistake that surely a package manager offering to
> remove 100+ packages should definitely sound an alarm.

Yep, and it sounds an alarm: "do you want to remove all this stuff,
*including* the meta?"

Vs "do you want to remove 1/10 of that stuff, most of which you never
heard of so who cares?"

> But with apt-get you will get only two packages uninstalled (the package
> with the conflict and the metapackage depending on it). The big surprise
> will come only later, when apt-get suddenly suggest you should run
> 'autoremove' to get rid of some 100+ packages that look like not needed
> anymore.

Yes. But it's easier to notice the removal of gnome (and stop it), than
the removal of one of the components of the platform, of which one
possibly never even heard of before, just uses, as it's part of the
platform.

On one hand, you have, in the depends case:

# apt-get remove gstreamer-plugins-good

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

Or in the recommends case:

# apt-get remove gstreamer-plugin-good

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

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

Similarly, depends protects the novice from removing parts of the
platform, it provides a guaranteed set of packages. For the advanced,
there are ways around the Depends, easy ways. Recommends does not
protect the novice, and offers very little advantage for the advanced.

>> As far as I'm concerned, this defeats the purpose of the meta-package,
>> because it breaks my expectation that whatever else it pulls in, will
>> stay there as long as the meta is installed.
>
> Did you consider creating your own meta-package? It shouldn't take you
> more than 5 minutes to write an apt hook to get the control file and
> s/Recommends/Depends/

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

--
|8]


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87pq80rvix.fsf@luthien.mhp">http://lists.debian.org/87pq80rvix.fsf@luthien.mhp
 
Old 07-13-2012, 07:09 AM
Gergely Nagy
 
Default Recommends for metapackages

Gergely Nagy <algernon@madhouse-project.org> writes:

>> Please don't forget that a Recommends will pull in packages in all but
>> unusual installations
>
> But also keep in mind, that once a package is installed, adding new
> recommends will not pull those new things in on an upgrade.

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

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

--
|8]


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87liiorvax.fsf@luthien.mhp">http://lists.debian.org/87liiorvax.fsf@luthien.mhp
 
Old 07-13-2012, 07:31 AM
Miles Bader
 
Default Recommends for metapackages

Jeremy Bicha <jbicha@ubuntu.com> writes:
> I don't claim to be a networking expert, but I believe half the
> conversation here is based on wrong or outdated information.

My (personal) complaint about NM is that it doesn't correct correctly
work with NFS mounts, I believe because it doesn't run at the right
time during bootup.

That's perhaps illustrative of more general practical and conceptual
issues with NM: it doesn't seem to be tested with much in the way of
non-standard setups, and in general seems to assume too many low-level
and central system tasks that arguably aren't appropriate for software
associated with a specific desktop (even if Gnome is installed on a
system to make some users happy, other users of the same system may
use some other desktop).

> GNOME considers NM to be part of GNOME Core, therefore gnome-core
> depends on it.

Debian need not slavishly follow how upstream thinks about things.

Plenty of upstreams have downright bizarre opinions about various
issues (often related to the not playing nice with others), but
nevertheless still make useful software. In such cases I think one of
the proper tasks of a distribution is to act as a buffer between
upstream and the users, installing the software in a way that works
well in the actual distribution, for actual users (as opposed to the
imaginary distribution and users upstream may be targeting).

Obviously this can be a lot of work, which is why it's generally a
good idea to defer to upstream's views when they are sane -- but that
isn't always the case...

-miles

--
Friendship, n. A ship big enough to carry two in fair weather, but only one
in foul.


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87txxcp15z.fsf@catnip.gol.com">http://lists.debian.org/87txxcp15z.fsf@catnip.gol.com
 
Old 07-13-2012, 07:38 AM
Timo Juhani Lindfors
 
Default Recommends for metapackages

Miles Bader <miles@gnu.org> writes:
> issues with NM: it doesn't seem to be tested with much in the way of
> non-standard setups

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


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 84bojk3ybc.fsf@sauna.l.org">http://lists.debian.org/84bojk3ybc.fsf@sauna.l.org
 
Old 07-13-2012, 07:39 AM
Miles Bader
 
Default Recommends for metapackages

Gergely Nagy <algernon@balabit.hu> writes:
> if upstream considers a package a core part of a platform,
> recommends *is* wrong.

Er, no.

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

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

-miles

--
Non-combatant, n. A dead Quaker.


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87obnkp0sx.fsf@catnip.gol.com">http://lists.debian.org/87obnkp0sx.fsf@catnip.gol.com
 

Thread Tools




All times are GMT. The time now is 10:39 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org