Hi, 2016-08-06 2:13 GMT+01:00 Christoph Anton Mitterer <[email protected]>: > 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.
I can only guess, but I think that the original motivation is that when you use stable or unstable, if some package is classified as Obsolete, is a reason to take special care about it, and so you can freely delete it if you don't care; or if you care, add it again to the archive (if was orphaned and deleted because it was an old version with low popularity but it's OK otherwise). This probably predates auto-installed, so it must have been a big deal back then to clear cruft. This doesn't mean that you don't have to take an eye on other packages that you mix and match from different sources. So Obsolete/Local doesn't have any relation to "how secure is to use a package or not". It's "whether it's still downloadable from somewhere" or "I could not find this package in any repo, but it's installed in this system". This maps quite direcly to other functionalities, like "the changelogs are only available locally" or "there are new changelogs in the server that the user might want to see before installing". Also, there's the peculiarity of testing, when packages are auto-removed and then pop back again into life, in the last few years. Each suite has its own peculiarities. Obsolete is pretty useless for this case of auto-removed packages. On the topic of security, you can have installed v1.3.1~rc1 of a package from experimental with dangerous bugs or security issues, and v1.2.1 from unstable will not be installed (in most common configurations), despite the risk for your system. Obsolete in aptitude and security don't have much to do with each other, it's only an artifact of mixing distros and only one of a myriad ways in which things can go obfuscated in terms of security when playing with different distros, pinning, etc. >> (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? Beause in Debian we really like to give the option of shooting themselves in the foot if they really insist on it. Freedom and all that. We're not so keen on babysitting the users and monitor them with twelve drones and raise an alarm in the police every time that they step into a pond, which might be small pothole in the roadside or might be a big lake. Basically the contributors of Debian strive to support the most common use cases, and it's hard enough, and a good enough gift to society, if you ask me. If people want to go playing around with our tools it's fine, but we don't want to be healing them or paying the healthcare after hurting themselves for using our tools in a way that we explicitly say that we don't want to support, even if they go handwaving all around. > 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). Since stable is the only suite that has guaranteed security updates, all of your considerations before are not relevant. unstable doesn't have security support, testing doesn't either, external repos can interfere with debian repos in ways that they take over, etc. So your only relevant use-case for security is when using stable+security, and there Obsoletes works well. > 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. Actually, the way in which I have seen people to use Obsolete is mainly to remove cruft, of packages that are no longer needed but are marked as manually installed for some reason (bugs in aptitude/apt/etc or not). I never heard of people worried about obsolete packages in terms of security, unless they are daemons or something special (often after stable updated to next-stable). Also, there's the peculiarity of testing, when packages are auto-removed and then pop back again into life, in the last few years. Each suite has its own peculiarities. Obsolete is pretty useless for this case of auto-removed packages. But well, testing was out of the picture at that time, auto-removals is relatively new and has low impact, and can be removed at any time, so... > 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. For aptitude it doesn't matter much what's in apt preferences. You can always select the version in the curses interface and install it. Since the classification of "Obsolete/Local" is, again, whether the version that you have it's only available in your system or whether it can be installed from another repo, it seems only natural that if there's another version from the package, it doesn't appear as "obsolete/local". Otherwise, how do you know that you can install other versions? One option would be to add an extra category, like "Upgradable", "Installed", "Installed but in a different version". This is easily achievable with patterns and Views and other things, for people who are into mixing distros. It's a complication in many ways, and not very useful for the main case that we want to support though, which is to use Stable, Testing or Unstable. That's why there's only two versions shown, "current" and "candidate". It's assumed that you will either be up-to-date now, or will upgrade when available. aptitude never really intended to change the interface in major ways for other cases, and doing so would be a really major undertaking. >> 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. I think that the problem is again that you are repurposing what Obsolete should mean instead of how it actually works and worked for almost two decades, when the problem is basically that aptitude was never thought for these cases. I don't think that it's particularly compelling to change it in those directions, and specially not with the reason of "security" -- it's a very tangential issue for this matter. > => 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) See above: you can perfectly choose this version in aptitude's curses to install. Thus is not "local/obsolete", you can actually install it from other repos. Chaging the meaning after 15+ years is not the way to go. > 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: Having the same package and version number is explicitly a recipe for disaster in the apt world, so this is another unsupported scenario. That's one of the reasons why DMO uses higher epochs -- to avoid this problem (as well as "take over" the package). >> > 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 It's the basic mantra in the free software world. $ ls --version ls (GNU coreutils) 8.25 Copyright (C) 2016 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>. This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. (the last line) The fact that people spend their time in making your life better doesn't mean that you can claim anything from them when things don't turn out the way that you want or expect. So maybe you should be a bit more grateful for the gift, rather than blaming the people giving the gift away for not supporting a case well enough (backports in this case). Cheers. -- Manuel A. Fernandez Montecelo <[email protected]> _______________________________________________ Aptitude-devel mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/aptitude-devel
