Version: 1.8.3 Severity: serious I have the following entries in my /etc/apt/sources.list: deb https://adoptopenjdk.jfrog.io/adoptopenjdk/deb/ disco main deb-src https://adoptopenjdk.jfrog.io/adoptopenjdk/deb/ disco main Currently, apt-get update gives errors about these sources: E: Encountered a section with no Package: header E: Problem with MergeList /var/lib/apt/lists/adoptopenjdk.jfrog.io_adoptopenjdk_deb_dists_disco_main_binary-amd64_Packages E: The package lists or status file could not be parsed or opened. However, I also get the same errors when I use apt-get install, apt-get upgrade or apt-cache policy, even when the package I'm trying to install, update or check the version of doesn't depend on adoptopenjdk. Shouldn't apt still be able to process the package lists from unaffected sources, and install and upgrade packages that don't come from or depend on the affected sources?
Hi, can e.g. parse everything first temporarily and only after that parse it again for real – practically doubles execution time – or you keep a snapshot of the previously parsed data so you can roll back in a pinch – practically doubles memory consumption. Both aren't a particular good idea as we always want to be faster & not waste memory so constraint [virtual or real] machines continue to work. So that seems "very difficult to fix due to major design considerations" (if you read on you might notice why I use that quote). What we could do is automating what is currently basically required from the user to do manually: Remove this crappy source. Would be nice, but as a new feature the appropriate severity is wishlist – and I wouldn't hold my breath for it as having such bad sources and wanting to keep them isn't a very common usecase… honestly, if the source doesn't manage to produce valid files I would have serious doubts about how good the rest of what they do is given I basically grant them root access to my machine by using it. So, that both being my reasoning for downgrading to wishlist. For your next bugreport it might be a good idea to not start out with a high severity as that will raise flags for many people to look at it, which end up being annoyed because the severity was overinflated. See https://debian.org/Bugs/Developer#severities for details on what the severities mean – which will a) explain the quoting from above and b) why "serious" is nearly always wrong. Thanks none the less for taking the time to report a bug and Best regards David Kalnischkies
Is there an alternative to apt that can use the same package repos, but process them in a fault-tolerant manner (e.g. load the merged-so-far list, try to merge the next source, save if successful, repeat)? If so, I'll want to switch to that, even if it means only having support for 10-year-old instead of 20-year-old hardware. I thought fault-tolerance and graceful degradation were important enough to the design of Debian that that would be a hard requirement.
Hi, nothing more) is cupt. No idea how that behaves, but it is certainly not a drop-in as it is kind of the point of it so if jumping ship is a good idea I will leave up to you. I still don't see what you gain by that, but okay: I will repeat just once that I would remove such a bad source instantly as in my eyes such a source can not be trusted with unchecked root access to my machine [which is practically what it gains by installing packages from there] even if they happen to produce a valid file in the future again… Best regards David Kalnischkies P.S.: That repo seems to provide a "buster" release (as in for Debian stable) instead of "disco" (for Ubuntu something) and that one seems to be syntactically valid… – at least it doesn't have the same obvious error in the file.