On Tue, Jul 09, 2019 at 06:52:58PM +0200, Julien Cristau wrote: > I think overall what you're trying to do here (the whole "notify the > user they're out of date" thing) does not belong in apt. IMO it belongs > in higher level tools that are going to heavily depend on the use case > and so there's not really a good generic answer you can come up with at > the lowest (apt) level.
Well, all user-facing clients use libapt for their equivalent of "apt
update". So your one-off python script, apt, apt-get, aptitude,
synaptics, all software centers, unattended-upgrades, apt-file … they
all share the code – and the data which is downloaded by one of them for
them all.
It is the choice of the frontend performing the update to present
encountered problems and apt{,-get} chooses to push the messages to the
usual list at the end of the run as it is common for apt. It could just
as well do nothing or open a blicking popup dialog, whatever seems
sensible for both the user using the current frontend AND for the other
frontends – so yes, there needs to be a default generic good answer on
the lowest level as we otherwise need to tell users to pick ONE frontend
and use that for the rest of their life exclusively.
Earmarking potentially dangerous data in hope that all frontends will
implement proper safety procedures while dealing with them doesn't work.
That was quite (in)visible for unauthenticated packages and I am very
happy we got mostly right of it by now.
apt{,-get} could choose to implement checks if the changed metadata
breaks its configuration – and we might do if I am really bored – but
that would indeed be lots of code and we still have the problem that the
other frontends might be broken by the new data.
#931524 and #931649 alone show that user config is easily broken & that
users frequently miss obvious and well-known changes to repositories. Or
did we already forget the recent outcry as oldoldstable left the
mirrors? And that is the main archive of your distribution. I doubt
users are following changes in 3rdparty repos they are using any closer.
I agree that apt{,-get} isn't the best place to keep you posted about
this stuff, but libapt is the best (because it is the only) place to
download the data all frontends can use and if present apt{,-get} should
make use of it as users expect it to help them. Even better if there are
higher level tools making better use of the data!
BUT that isn't about notifying users or breaking configuration even if
that is the most visible in practice. You don't have to look particular
far for an opportunity to create disaster (at least in the eyes of the
user) if you allow an attacker to change one metadata field:
http://deb.devuan.org/devuan/dists/stable/Release
http://deb.devuan.org/merged/dists/stable/Release
The two release pockets differ by Suite only. [Okay, they differ by
Label, too, so apt would catch that – but that looks more like an
accident than deliberate. And how much impact can a Label change have…
that should be automatic, too! btw "Debian stable" and "Debian
stable-security" differ by Label only in buster].
(not an endorsement btw, just a semi-random pick from the census)
Or because everyone loves docker lets look there:
https://download.docker.com/linux/debian/dists/buster/Release
https://download.docker.com/linux/debian/dists/stretch/Release
https://download.docker.com/linux/raspbian/dists/buster/Release
https://download.docker.com/linux/ubuntu/dists/artful/Release
https://download.docker.com/linux/ubuntu/dists/zesty/Release
These indeed differ by Suite only and are therefore freely exchangeable
if we allow unsanctioned Suite changes.
Having Oracle in your trusted keyring? Great! Then I will serve you this
the next time you request the Debian unstable repository:
https://oss.oracle.com/debian/dists/unstable/main/binary-i386/Release
[caught by codename – or more realistically by signed-by, expect nobody
uses that. MR !33 to the rescue but this requires correct and relatively
stable metadata as well]
The last one is just the literally first hit on duckduckgo for '"Origin:
Debian" Release' for me. It isn't particularity hard to find others with
better usability factors.
So if the proposed solution is over engineered I am all ears for
alternatives which deal with these issues.
Best regards
David Kalnischkies
P.S.: Pinning and other actions in libapt by codename was the first big
feature I implemented a decade ago. So in Debian terms it isn't that old
and indeed lots of documentation still uses suite names for this – and
in many cases that isn't wrong. Other frontends got that feature even
later – assuming it is implemented at all by now. Reading mails worded
as if codenames were a universal truth is quite funny in that context.
signature.asc
Description: PGP signature
