Your message dated Tue, 10 Nov 2015 00:18:19 +0000
with message-id <[email protected]>
and subject line Re: idea: making aptitude ignore sets of packages entirely
has caused the Debian Bug report #138843,
regarding idea: making aptitude ignore sets of packages entirely
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
138843: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=138843
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: aptitude
Version: 0.2.10-1
Severity: wishlist
Here's my dilemma: I'd rather not deal with all the crap in non-free.
However, I do use mame, which is sadly non-free. So I can't just
remove non-free from my sources.list; gotta get those mame updates.
But I'd like to never see another non-free package dragged in,
especially from bogus suggests. (Tons of bugs filed on stuff that
suggests netscape, BTW.)
So, I'd like to do something like limit aptitude to something like this:
!(~snon-free|~scontrib)|~nmame
(or maybe allow all games in non-free to get through) except a limit is
not good enough. I don't want to just not see the packages, I don't want
aptitude to even act like they exist at all. Don't upgrade them, don't
let dependencies pull them in. I don't think limits do this, do they?
-- System Information
Debian Release: 3.0
Architecture: i386
Kernel: Linux silk 2.4.18 #1 Tue Feb 26 00:23:37 EST 2002 i686
Locale: LANG=C, LC_CTYPE=C
Versions of packages aptitude depends on:
ii apt [libapt-pkg-libc6.2- 0.5.4 Advanced front-end for dpkg
ii libc6 2.2.5-3 GNU C Library: Shared libraries an
ii libncurses5 5.2.20020112a-5 Shared libraries for terminal hand
ii libsigc++0 1.0.4-2 Typesafe Signal Framework for C++
ii libstdc++2.10-glibc2.2 1:2.95.4-4 The GNU stdc++ library
--- End Message ---
--- Begin Message ---
tags 138843 + wontfix
stop
2002-03-18 04:31 Joey Hess:
Package: aptitude
Version: 0.2.10-1
Severity: wishlist
Here's my dilemma: I'd rather not deal with all the crap in non-free.
However, I do use mame, which is sadly non-free. So I can't just
remove non-free from my sources.list; gotta get those mame updates.
But I'd like to never see another non-free package dragged in,
especially from bogus suggests. (Tons of bugs filed on stuff that
suggests netscape, BTW.)
So, I'd like to do something like limit aptitude to something like this:
!(~snon-free|~scontrib)|~nmame
(or maybe allow all games in non-free to get through) except a limit is
not good enough. I don't want to just not see the packages, I don't want
aptitude to even act like they exist at all. Don't upgrade them, don't
let dependencies pull them in. I don't think limits do this, do they?
That would only work as far as mame would decide not to add new
dependencies on other non-free packages, otherwise it will need tweaking
every time. Maybe that's easy to do with a package that doesn't change
much, but it doesn't scale if there are more than a few packages from
non-free (or any other place installed) or if the dependencies changed
often.
Worse, this would complicate aptitude and would possibly create
confusion to many aptitude users when new dependencies were added and
broke these packages, in the same way that they are very confused and we
receive reports every time that packages cannot be installed due to
transitions, or packages that depend on virtual and temporarily
uninstallable packages.
In short, too much hassle for a very specialised corner case and with
potentially problematic ramifications.
2002-03-18 11:58 Daniel Burrows:
Hm, I was going to say that I wouldn't be able to do this without
reimplementing apt's dependency handling.
But actually, this only makes sense for Recommends and Suggests, and I
already have to tell apt when to install those. So this wouldn't be too
hard to implement.
But there would be similar problems for Depends, Replaces, etc, I
suppose.
2002-03-18 17:30 Daniel Burrows:
On Mon, Mar 18, 2002 at 12:27:08PM -0500, Joey Hess <[email protected]> was
heard to say:
Daniel Burrows wrote:
> Hm, I was going to say that I wouldn't be able to do this without
> reimplementing apt's dependency handling.
I figured you could do something like just deleting the excluded
packages out of your in-memory package list at startup or something.
There's no way to do that in the apt API, and strict Depends still need
to be tracked anyway.
Exactly...
2002-03-20 17:16 Daniel Burrows:
Well, I really like this idea. Unfortunately, while working on it, I
realized that I can't really implement it in a workable way.
I can only exclude dependencies from consideration entirely; I can't
exclude the use of particular packages/versions to fulfill them. For
instance, I can prevent any non-important dependency on "mpg123" from being
considered; however, I cannot prevent mpg123 from being installed and
allow mpg321 to be installed.
Given that there are other feature requests pending, I'm going to put
this one aside for now. Sorry.
Exactly, again.
After 13 years, I think that it's safe to mark it as +wontfix and close,
it didn't see any other seconds or attempts to implement it in these
long years, and given the (still) much higher priorities --not only with
new features, but with existing and important problems--, this would not
be tackled any time soon anyway.
So closing.
--
Manuel A. Fernandez Montecelo <[email protected]>
--- End Message ---
_______________________________________________
Aptitude-devel mailing list
[email protected]
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/aptitude-devel
