what do you want to see in future apt versions ?

[Tom H]

On Sun, Jun 7, 2020 at 8:29 PM Ralf Mardorf via ubuntu-users
<ubuntu-users at lists.ubuntu.com> wrote:
> On Sun, 7 Jun 2020 19:41:27 +0200, Tom H wrote:
>> On Sun, Jun 7, 2020 at 7:20 PM Ralf Mardorf via ubuntu-users
>> <ubuntu-users at lists.ubuntu.com> wrote:
>>> On Sun, 2020-06-07 at 18:25 +0200, Tom H wrote:
>>>>
>>>> Perhaps the "dist" in "dist-upgrade" is confusing, but apt/apt-get
>>>> aren't different from other package managers. dnf, pacman, yum (and
>>>> zypper, I assume) will upgrade you to the next/the devel release if
>>>> you enable that new release's package index.
>>>
>>> pacman it the tool of Arch Linux, a _real_ rolling release. There
>>> isn't a "next" release package index, since there is no "next"
>>> release.
>>
>> I said "devel" but in the Arch world it's called "testing."
>
> No it's not a "devel" release or "testing" release, it's just an
> additional repository. The "testing" repository does not contain all
> packages. It needs packages from stable. However, from the Ubuntu
> repositories it would be "backports" that's closest to Arch's "testing"
> repo. You mentioned "if you enable that new release's package index",
> but it's not a new release. A new release doesn't exist. Ubuntu
> "backports" aren't a new release either, "backports" provide newer
> versions, but compiled against the current release libraries.
>
>>> Apart from the stable repositories Arch Linux has got staging and
>>> testing repositories. It doesn't make much sense to enable the
>>> testing repositories, but it could be done.
>>
>> Someone has to. The developers for example. And not just the
>> developers. I've seen bugs where users report problems with a package
>> from "testing." Or else new packages aren't tested before being
>> released for general use.
>
> From https://wiki.archlinux.org/index.php/Official_repositories :
>
> "testing contains packages that are candidates for the core or extra
> repositories.
>
> New packages go into testing if:
>
>     They are destined for the core repo. Everything in core must go
>     through testing
>
>     They are expected to break something on update and need to be
>     tested first."
>
> It's the same release, just the packages aren't necessarily stable.
>
> "Disabling testing repositories
>
> If you enabled testing repositories, but later on decided to disable
> them, you should:
>
>     Remove (comment out) them from /etc/pacman.conf
>     Perform a pacman -Syuu to "rollback" your updates from these
>     repositories."
>
> Rollback to packages from the stable repository, but not to a former
> release. A rolling release without releases and freezes needs the
> staging step:
>
> "Staging repositories
> Warning: Do not enable the staging repositories for any reason. Your
> system will unquestionably break after performing an update. This
> repository is only meant for backend developer use.
>
> This repository contains broken packages and is used solely by
> developers during rebuilds of many packages at once. In order to
> rebuild packages that depend on, for example, a new shared library,
> the shared library itself must first be built and uploaded to the
> staging repositories to be made available to other developers. As
> soon as all dependent packages are rebuilt, the group of packages is
> then moved to testing or to the main repositories, whichever is more
> appropriate."
>
> The people who need to enable testing are testers. And it must be
> repeated: "Everything in core must go through testing"
>
> There are no releases!

Many thanks. So whether the "testing" repo has 1 or 1,000 packages or
whether it has 1 or 1,000 users, just like any other package manager
in Linux or BSD, to install 1 or 1,000 packages from a specific
repository (no matter what it's called or its purpose might be), you
have to enable it in the config and update the local package index.