Public bug reported:
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
** Affects: apt
Importance: Undecided
Status: New
** Affects: apt (Ubuntu)
Importance: Undecided
Status: New
** Affects: apt (Debian)
Importance: Undecided
Status: New
** Tags: amd64 apport-bug disco
** Also affects: apt
Importance: Undecided
Status: New
** Also affects: apt (Debian)
Importance: Undecided
Status: New
** Description changed:
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 big a task, however affects ubuntu
+ release models far more significantly.
+
+
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
** Description changed:
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 big a task, however affects ubuntu
- release models far more significantly.
+ 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
--
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:
New
Status in apt package in Ubuntu:
New
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/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
