Re: 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]
Reply to: