On Thu, Jul 11, 2013 at 2:27 AM, Vincent Lefevre <vinc...@vinc17.net> wrote: > On 2013-07-10 20:52:15 +0200, Julian Andres Klode wrote: >> On Wed, Jul 10, 2013 at 04:44:46PM +0200, Vincent Lefevre wrote: >> > But this can be preferable if the removed package has security bugs >> > and has been removed for this reason (the user wouldn't be aware of >> > that with the current behavior of apt). >> > >> > Perhaps another solution rather than downgrading is to warn the user >> > that something is wrong.
Lets assume for a second that APT could really work-out if a package is missing from an archive now: What should I do with this list? I am lacking metadata on why the package disappeared from this archive. It could be that the current versions can't be fixed to be usable again (stable, e.g. youtube-dl: wanna try backports?), that upstream is death (the following alternative exist: …), the package is not fit for release in its current rc-buggy state (wanna help?) as it FTBFS (temporary help?) or has no maintainer anymore taking care of it (seriously, wanna help?). Maybe it its now non-free (alternatives? Maybe add non-free?) or its gone from a (derivative) archive as its now in Debian proper (everything fine) … Oh, and of course: liblibrary1 can be removed after all users are converted to liblibrary2 (but don't tell the user that liblibrary1 just disappeared from the archive, nobody cares…) and even though "raider" is removed, "twix" takes over the functionality completely, so don't be so scared to remove it APT and don't scare the user as well … This metadata exists already: The release notes include a reason for the removal of a package from stable, archive removals have in the request mail a reason (and a list of alternatives) by definition and britney acts on hints which come usually with a comment on why. For the second part, the information is usually only available in the head of the maintainer (and maybe in the changelog). If we could collect and access this kind of information APT could do something, but without we have a big pill of changes which might or might not be noteworthy, and the "uninteresting" changes are by far in the majority… >> I don't think it is possible to do this in any sane way. For example, >> if you locally rebuild your package, adding something like +local1 to >> the version; that version won't be available from any source; but you >> still don't want APT to complain that you installed a locally-built >> package. > > To avoid such problems, apt could remember where an installed > package came from. Such information, that could be stored in > /var/lib/apt/extended_states, could also be useful to other tools, > such as apt-show-versions. The information would be interesting, yes, but beside that nobody has implemented that sofar, I guess it has some problems depending on how its implemented: A package installed from unstable, which migrates to testing – was this installed from unstable or from testing? And if a package is in testing and in unstable, what is the origin? Maybe such an origin field should just include "Debian" and be inserted at build-time of the package and included in dpkg/status – surprisingly it already seems to exist, but only src:dpkg packages use it …? Best regards David Kalnischkies -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
