APT is maintained by 2 people, encouraging a discussion on every bug report that will likely get ignored anyway would be madness. I think closing the bug as Opinion is a much better choice than ignoring it for 10 years or so like most other bugs are.
* Various tools would be broken by such a change * Having variables in the files looks bad * Having variables in the files makes it harder to debug * The variable may be misleading, as your distribution may not override os-release files * It does not work on Debian, as testing/unstable have the same os-release file * Debian's lsb_release relies on sources.list to figure out which release you are running on You also can't upgrade with this: If we seed the variable from os- release, we seed it from os-release, and that comes from a package in that repository - the repository defines the versions installed, not the versions installed the repository. Now you could say "let's temporarily override that in the code" but ugh this is not really all that elegant and it gives different tools different views of things at runtime. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apt in Ubuntu. https://bugs.launchpad.net/bugs/1835645 Title: apt sources should be able to understand release variables Status in apt package in Ubuntu: Opinion Status in apt package in Debian: New Bug description: apt sources conventionally use a fixed release name. But this causes both adding repos as well as upgrading an unnecessarily painful experience. For instance, adding a simple package requires adding the keys with `apt-key` and then adding the repo, and then apt update/apt install. 3 different steps also complicate install scripts. Distros like fedora, RHEL handle this rather gracefully with `releasever` which makes for a consistent experience. Similarly, updating ubuntu on desktops every 6 months causes unnecessary waste of time, having to upgrade the sources with say "bionic" to "disco", and such in the apt sources. Currently, ubuntu attempts this on a superficial level by just changing swapping out the release names for what it can, and disabling the others. This is both fragile and causes an inconsistent upgrade experience. I think it's time that this is simplified, and potentially handled by apt utilising release variables and names from `/etc/os-release`. In case of upgrades, I personally think it's completely okay to use a releasever variable based external repo that doesn't exist yet (and might start working once upstream catches up), rather than just disable it. However, using ubuntu release models, releasever ideally has the option of utilising an option of LTS, so some external packages that only does this conservatively on LTS can target a repo source url that does just that (while this seems fragile technically, practically it works as most LTS repos work rather well) In case of Debian, the above problem is actually not as magnified due to slower release and consistent names like `stable`, `oldstable` and `testing`, which makes upgrading not as big a task, however affects ubuntu release models far more significantly. I'm marking this as a bug, since I think this is a significant UX dent for today's distros - so much that other most significant other distros don't have such a painful experience. ProblemType: Bug DistroRelease: Ubuntu 19.04 Package: apt 1.8.1 ProcVersionSignature: Ubuntu 5.0.0-20.21-generic 5.0.8 Uname: Linux 5.0.0-20-generic x86_64 ApportVersion: 2.20.10-0ubuntu27 Architecture: amd64 CurrentDesktop: GNOME Date: Sun Jul 7 13:05:04 2019 InstallationDate: Installed on 2019-06-23 (13 days ago) InstallationMedia: Ubuntu 19.04 "Disco Dingo" - Release amd64 (20190416) SourcePackage: apt UpgradeStatus: No upgrade log present (probably fresh install) modified.conffile..etc.apport.crashdb.conf: [modified] mtime.conffile..etc.apport.crashdb.conf: 2019-06-29T23:49:14.971566 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1835645/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
