[Bug 1835645] Re: apt sources should be able to understand release variables

[Prasanna V. Loganathar]

@juliank - my suggestion is use variables in apt provides an option.
It's not forcing a design decision of how it must be done. Fedora/RHEL
is a good example of where it works and has dispels your empty argument
that it causes a terrible user experience.

However, based on your comment, what disagreement is your opinion,
without having the choice, which is what makes for a terrible user
experience.

Also, I suggest considering or encouraging an open minded discussion,
rather than switching status to opinion without community engagement
whatsoever. I find this a bit disturbing to engage.

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, 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