tag 768047 + security severity 768047 important retitle 768047 aptitude: doesn't inform a user that a package will no longer receive updates when it obsolete in the target suite, but not yet for an older suite
Hi Axel. I always wonder what the reason is for people to change other peoples bug reports titles, tags, severity, etc., without any further consultation of these people who probably didn't just choose them by chance. Sometimes it seems to be hiding away issues, arrogance (i.e. "I think I know better, and change that now without further discussion") or perhaps ignorance (i.e. not having checked closely enough or understood whether something is a severe problem or not). Don't get me wrong, I don't mean that I wouldn't make mistakes or my opinion is higher than others,... but shouldn't it be usually require some discussion what really applies or not, if just out of politeness? Otherwise we could simply drop reporting any severity/tags completely, since you'll always find someone who disagrees. But since you seem to be neither member of the security team (and I guess even that is probably not the ultimate group to decided where the security tag applies to) or maintainer of aptitude (or did I miss something),... I don't see why your arguments that this is a non-issue should be stronger than mine that it is. Therefore reverting severity and tags. As for the title: It took me a while to understand what your new suggestion actually means, and I think it's a bad title, cause it implies that a feature is wanted that shows (and therefore in the end also installs) packages from anther suite, even if those packages where deselected via explicit apt_preferences policy configuration. Clearly not what the user wants, and clearly not what aptitude should do with any feature. Just because e.g. lcms1 is no longer upgraded in unstable, this should mean that aptitude proposes it to downgrade to a "new" older version, when a security update comes out. What is really wanted is, as I've tried to describe before, a feature that shows people for which they no longer get updates. I did though give another title, than my original, which should make more clear now what is missing. > ... which is correct because it isn't obsolete as it's still > downloadable. > > Please see the documentation how the "obsolete" filter and grouping > is defined in aptitude: > > "This term matches any installed package which is not available in any > version from any archive. These packages appear as “Obsolete or > Locally Installed” in the visual interface." Well I've seen that, but this probably simply isn't perfectly defined in the light of having multiple suites with different statuses of the same package. The category isn't *just* "locally installed packages" it's "obsolete *and* locally installed packages". When having only one suite, and a package is dropped from that (which implicitly means "user, you won't get any further updates"), than things obviously match that definition, as you say. But as soon as you have multiple suites enabled (for the same repo), or especially when you also have things like snapshot.d.o enabled, that definition of "obsolete" makes no longer much sense, since one likely always finds a suite where one can download a package from. For the user, who has such a package already installed, the information "you cannot donwload this anymore" is rather useless anyway, why should the user want to download it again, he already has it installed. The information that is of interest in the end is: "this package is no longer part of the repo and will no longer be updated". Now in the multi-suite scenario I've described it *is* of course still part of some repo, but not of the user's "main" repo. > > which of course also means that I wont't get any further (security) > > upgrades for it in unstable and of course I won't get upgrade to > > stable as well, since lcms1 isn't what I'm selecting via > > apt-preferences. > > This is IMHO in the user's responsibility if he decides to mix stable > and unstable. Well that basically ends up in the same discussion and questions that were already asked here #752450 (respectively in some parts on d-d, where some people removed the bug from being CCed): IMHO (and some other people agreed), there should be a systematic way of informing people about updates and especially also when a package runs out of support. Systematic way in the sense, that apt/aptitude tell you, and not that the user has to manually collect that information from all kinds of places (not to talk here about the security implications which this in turn has, and which is more thoroughly discussed in the aforementioned bug. The situation I've described here however, i.e. unstable/stable mix, there is now real obvious way for a user to check that. DSAs would be only issued for stable/testing,... any one probably cannot demand users to regularly read: http://ftp-master.debian.org/removals.txt You also cannot just say it's "user's responsibility if he decides to mix stable and unstable", because this would basically limit one to only mix oldstable/stable/testing with each other, and to not mix in any other repo at all. Cause the same issue obviously applies when I take e.g. ffmpeg from DMO and if that would remain there supported on a lower version, while I have the Debian ffmpeg on a much newer major version (in the case it would be dropped from unstable). > Actually aptitude already offers you the tools to find such packages. > Just build the according view filter, e.g. call: > > aptitude -o "Aptitude::Pkg-Display-Limit=~i ?any-version(~Osecurity) !~U !~o" Just tried that on the lcms1 example (having installed it from testing since it's gone from unstable, but completely disabled the testing repo again afterwards - should be the same situation as if it would have been just dropped from unstable), so back to the situation: A version is installed that is no longer in the target suite for that very package (unstable), but still available in some other suite (stable). That invocation doesn't show any package at all in aptitude. > It's untested as I don't seem have any package in such a state, but > based on what I use to emulate apt-show-version's "newer than in > archive" with aptitude: > > aptitude -o "Aptitude::Pkg-Display-Limit=~i ?any-version(!~O.) !~U !~o" same as above, nothing is shown at all. > Downgrading to wishlist as this is clearly a feature request and not a > bug -- it works as designed. Also removing the tag security as > security updates for unstable are official not available, as you > already mentioned, hence your scenario is not officially supported > either. Well as I laid out before if it's designed like that than it's nevertheless a bug, i.e. the missing way of telling a user per default that he won't get further updates.. And for the security tag: That seems to be defined as: "This bug describes a security problem in a package (e.g., bad permissions allowing access to data that shouldn't be accessible; buffer overruns allowing people to control a system in ways they shouldn't be able to; denial of service attacks that should be fixed, etc). Most security bugs should also be set at critical or grave severity." which just perfectly applies, the current way of handling things, allows a package to get into a state where it's no longer update, without anyone ever noticing it. The definition doesn't tell, that it would only apply to security supported suites. That being said,... we can probably argue about the severity, whether it is wishlist or not. But I don't think we can about the security-tag. And IMHO, one of they key duties of apt/aptitude is package management inculding keeping the system up-to-date,... and if the current design doesn't fulfil this, even if just in some corner-cases, it's at least more than just a wishlist. I mean if gnupg would tell you that any signature is okay, even if just in some cornercases, you'd probably still consider it an important security bug, if not rather a critical one. Cheers, Chris. _______________________________________________ Aptitude-devel mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/aptitude-devel
