Mhh... a bit further below in the text, aside from all the discussion about whether this is supported or not,... I might have found some way to go how aptitude could easily (at least semantically) identify packages which are obsolete in the sense of: will this package (in the current apt_preferences/sources.list config) still receive updates (assuming that the repos themselves are still maintained) or not.
Not sure how difficult it would be to implement the abstract criterion into actual code, though ;) Anyway, if you're as tired about the political discussion whether things is de jure / de facto supported or not, just skip on to (*). If it would be easy to implement, you could either replace the current "obsolete packages with it" (as I try to motivate below, it doesn't make that much sense in the current form), or perhaps add it as a new category, "packages that don't receive updates in the current config". On Sat, 2016-08-06 at 01:12 +0100, Manuel A. Fernandez Montecelo wrote: > The underlying problem is that you think that using Debian + external > repositories which don't play well with Debian is a supported > scenario. Well "supported" is always a relative thing. It may not be supported in the sense that someone from Debian feels officially responsible, but it's actively and actually quite powerfully supported on the technical side starting with sources.list allowing for multiple repos up to e.g. the mechanisms of apt_preferences. So why not making these situations safe, simply by properly telling users when their packages won't receive anymore updates? It's a bit cheeky to have all these mechanisms in Debian, actually advertising them in the documentation, for quite a while even depending on them (e.g. when DMO was the only resort to get usable multimedia capabilities into Debian),... and on the same time saying: "nope, don't want to properly (technically) support these functionalities). At least I found no reference in the sources.list, apt_preferences or aptitude manpages that things will be insecure in certain situations, when multiple repos are used. > "In most situations if you stick with one distribution you should use > that and not mix packages from other distributions. Many common > breakages arise due to people running a distribution and trying to > install Debian packages from other distributions. The fact that they > use the same formatting and name (.deb) does not make them > inmediately > compatible." This quite clearly refers rather to the problems resulting from dependencies than to package management software not properly detecting situations in which software is really obsolete. > (there are similar warnings about mixing different Debian > distributions/suites except in completely compatible overlays, e.g. > "security") Well than why not hardcoding all these repos, and no longer allowing people to configure them? Why not dropping apt_preferences if it's anyway "not supported" and can just cause insecure situations? > If DMO had transcode as a well supported package (perhaps packaging a > maintained fork while keeping the same name, for example), it > wouldn't > be a security problem at all, you could switch to it instead. Not if one has pinned it down via apt_preferences before. Again, I really think that the question of whether DMO is well [security]supported or not is completely out of question here. And there are so many security questionable things in Debian, that it's probably not appropriate to point at other "projects", either. > From > aptitude's POV, it's not "obsolete", because it's present in other > repo. And as I've said, that's the problem. Think about it this way: What is the motivation behind having the knowledge "whether a package is obsolete or not"? If one hasn't installed it in the first place, then knowing that package foo is now obsolete is pretty much useless from the package management PoV. Sure one can see: Debian has had this in the past, but not longer. So what? If one has it installed, what's the use of seeing that it's now obsolete? I'd say either: - To see that one can remove it safely in case of dependencies cannot longer be fulfilled because of it. - To notice that this is basically out-of-Debian-warranty (i.e no more updates - whether security or not). The former case is probably largely irrelevant, either other packages Conflict/Break/Replace/etc. the obsolete package already (and then I don't need the info that's is obsolete) or they don't (and then I could just keep the obsolete package if I don't care for security/new versions). So IMO the important case if the 2nd. Now just not getting new upstream versions (with new features) is perhaps nice to know, but not knowing it doesn't hurt one much either. If new features are missed people will search and find out whether package foo is upstream-dead or just gone from Debian. In the end, what's really interesting about obsolete packages is: package foo won't get any further security updates. If you continue to use it, you're on your own. This information is currently not available to aptitude users, when they do *anything* that uses multiple repos, except those which are fully aligned (e.g. stable + security updates). > The fact that it was removed from unstable is not an indication that > it's a security problem either. Sure, but a) I haven't said that the status should indicate that there *is* a security problem, but rather that an obsolete package won't get any further updates (including security updates)... and b) in reality it's quite likely for many packages that using a no longer updates version will actually end up in security problems. And as I've said just above... if one doesn't care about security updates, than having the information whether something is obsolete or not is pretty pointless. Either one hasn't installed it and then it's simply gone... or one has it installed and can just happily continue to use it. > The only solution for this particular problem is DMO stopping to ship > this package, if it indeed has security problems; and for this and > the > more general problem of packages dropping from repositories while > present in others is you to monitor such packages, with the tools > that > aptitude gives to you (and Obsolete is the wrong tool in this case). As I've said above, DMO (or any other repo) can't do anything about it, when the user pinned down the packages from it to a very low priority. I have e.g.: Package: * Pin: origin "deb-multimedia.org" Pin-Priority: -1 and just selectively enable: Package: libdvdcss2 Pin: release o=Unofficial Multimedia Packages Pin-Priority: 500 Whether or not the DMO version is properly security maintained, doen't matter at all, since my apt_preferences "disabled" it. The Debian version however is kept, without any indication that it's gone. > It's not a security problem related to Debian or aptitude in any case it is... the problem is that the definition of "Obsolete" as it is now is pretty useless, or at least questionable with respect to security. (*): A simple (but AFAIU not really complete) workaround could be to define "obsolete": Package foo is obsolete, if the installed version is the same than the canidate version, and if this version is only present locally. Examples: $ apt-cache policy mplayer mplayer: Installed: 2:1.3.0-3 Candidate: 2:1.3.0-3 Version table: 4:1.3.0~20160702.svn37873-dmo1 -1 -1 http://deb-multimedia.org unstable/main amd64 Packages *** 2:1.3.0-3 500 500 http://ftp.de.debian.org/debian unstable/main amd64 Packages 100 /var/lib/dpkg/status => all fine, versions are the same, but it's still in unstable/main $ apt-cache policy mplayer mplayer: Installed: 2:1.3.0-3 Candidate: 3:2.3.0-3 Version table: 4:1.3.0~20160702.svn37873-dmo1 -1 -1 http://deb-multimedia.org unstable/main amd64 Packages 3:2.3.0-3 500 500 http://ftp.de.debian.org/debian unstable/main amd64 Packages *** 2:1.3.0-3 500 100 /var/lib/dpkg/status => installed version no longer in a remote repo,... but another candidate version is already selected (=> assuming that this will lead into a track that's kept up-to-date) $ apt-cache policy mplayer mplayer: Installed: 2:1.3.0-3 Candidate: 2:1.3.0-3 Version table: 4:1.3.0~20160702.svn37873-dmo1 -1 -1 http://deb-multimedia.org unstable/main amd64 Packages *** 2:1.3.0-3 500 100 /var/lib/dpkg/status => no different candidate, and only left in /var/lib/dpkg/status. While there are repos left that have the package (DMO), their version is apparently not selected, thus one must assume that from the current apt_preferences config, mplayer is "obsolet" (in the sense of: it won't receive any updates) The problem with this approach is: Another the package/version combination from another repo could be disabled via pinning and also have the same version number as the installed one: mplayer: Installed: 2:1.3.0-3 Candidate: 2:1.3.0-3 Version table: *** 2:1.3.0-3 500 -1 http://deb-multimedia.org unstable/main amd64 Packages 100 /var/lib/dpkg/status => BOOM! versions are the same, package still in a non-local repo, yet one won't get any updates to it. Perhaps one can solve that with the priorities (but this has changed in recent apt versions and I kinda miss the in-depth-insight): E.g. if the local installed priority would be always 100, then one could refine the above criterion to: A package is obsolete (in the sense it won't get any further updates) if all of the following applies: - candidate version = installed version - all available sources for that version are either local (/var/lib/dpkg/status) or have a priority lesser than (or equal to?) 100. > actual problem is that you think that you can use both unstable and > DMO and report bugs as if it was a supported scenario ;) :-P You already do support this, or does aptitude bail out with an error if it seems multiple different versions? > https://backports.debian.org/FAQ/ > > Q: Is there security support for packages from backports.debian.org? > > > > A: Unfortunately not. ... > > So, basically, mixing repos is not supported because it leads to this > kind of problems, not even backports is 100% safe. And yet there is backports and it's not just some experimental meadow for fun but people do actually use it. > > > t's quite well known in the community, really. Aha,... and yet it's there to be used?! I think it's a bit cheeky if we say on the one hand: - here are the backports, this makes your live so nice (which it does) - have some small written notice somewhere which says "this is not supported", which people typically won't read at all and even if they'd do, not care simply because "everyone else" uses backports as well - not warn (via package management) if things really run out of support Cheers, Chris.
smime.p7s
Description: S/MIME cryptographic signature
