2010/5/26 Jonathan Nieder <jrnie...@gmail.com>:
> Marking the dependencies of a metapackage as manually installed has
> the huge downside that there is no easy way to remove that suite of
> programs later.
The question is: How often do you do this?
Is it more common that a user installs a metapackage and want to
1. get right of all packages later OR
2. remove one package later (causing the remove of the metapackage)
??
I also see a difference here in the "remove because i don't like it" and
the "remove because i don't need it" - the second is what autoremove
should do and the first is for the user and remove/purge.
I think if i say $ apt-get purge gnome
i state that i don't like gnome and want to get right of it -
in an ideal world gnome and stuff will be removed now,
the libraries and other auxillary dependencies later with
autoremove.
So what you really mean was
$ apt-get purge gnome all-depends-of-gnome
If i say $ apt-get purge epiphany-browser
which causes the remove of the gnome metapackage
i state only that i don't like this browser, not that i dislike
the complete gnome stack, so autoremove should take care
of the packages epiphany depended on, not the one gnome did.
> For metapackages, as I think was discussed on debian-devel, it seems
> better to use Recommends. I don’t know what APT does when a
> recommended package is removed; maybe a "sticky" bit would also be
> needed to avoid removing the metapackage just because one of its
> components was removed.
I think using recommends for it is not the best idea…
APT ignores "missing" recommends (beside in --fix-policy) as they
are not really needed and will also not install (new) recommends as
APT will never know if the user chose to not-install the recommends,
even removed the recommends before or if the user want it installed…
A "sticky" bit is a problem in this sense as you will need to tell
$packagemanager and dpkg to ignore dependencies if the user
requests it -- that is the third cycle of dependency hell:
I can imagine thousands of users ignoring some "strange" library
packages wondering later on that the application is crashing
so you will soon ask for a way to forbid the ignorance of
certain dependencies again…
(The first cycle is btw third-party repositories as they tend to
generate "interesting" upgrade-problems and the second is
hold and pinning as it is done wrong too often - don't get me
even started on the other four cycles ;) ).
And last but not least, at least a few metapackages
should be converted to Tasks.
… but this becomes really offtopic now …
>> I am currently thinking about transferring the auto-bit for disappeared
>> packages with the theory that a disappeared package only depends on
>> the package(s) replacing it - beside packages needed for the maintainer
>> scripts - but these should be eliminated with a check if the dependency
>> replaces the package…
>
> Sounds dangerous. Consider that every package implicitly Replaces the
> empty directories from every other package, and you can see this
> becoming counterintuitive.
Huh? I don't get what you mean, so let me give an example:
Package: oldPkg
Depends: newPkg-client, newPkg-server, awk
Package: newPkg-client
Replaces: oldPkg
Package: newPkg-server
Replaces: oldPkg
Package: awk
Replaces: (not oldPkg)
In this case, if oldPkg disappeared i would assume that newPkg-{client,server}
should be marked as manual (if oldPkg was manual) as they seems to
be the follow up packages of oldPkg. awk on the other hand seems to be
just still a depends to be able to execute maintainerscripts successful.
Nothing implicit
Best regards,
David Kalnischkies
--
To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/aanlktik4n7dbdcbvqbmeaujudyzprbw0zc729bqay...@mail.gmail.com
