On 30/06/2021 13:54, Rafael Fontenelle via aur-general wrote:

Hi Markus

On Wed, Jun 30, 2021 at 6:45 AM Markus Arians via aur-general wrote:

...

Hi everyone,

today I noticed I was unable to push to the AUR repository for the pijul package with the server hook error message "remote: error: package already provided by [community-testing]: pijul".

Sure enough, the package exists in the Community-Testing repository (see https://archlinux.org/packages/community-testing/x86_64/pijul/).

Now, as far as I understand, packages can be "promoted" to the community / community-testing repository, however, in this case it seems like a new package with the same name has been created. Is this the usual procedure? What will my responsibilities as packager of the AUR pijul package be? What happens to the AUR package? Should I just leave it as it is? Submit a delete request?

Thanks for your help! Markus My suggestion is to file a delete request. That's what I do when one of my AUR packages goes to an official repository.

Best regards, Rafael Fontenelle

The question if the package will ever make it to community - most people won't have community-testing enabled. It's not very typical for new packages that weren't in the repositories before. My guess it was because an alpha version was packaged, which shouldn't have been packaged in the repos in the first place. Alad

On 6/30/21 9:35 PM, George Rawlinson via aur-general wrote:

On 21-06-30 15:05, alad via aur-general wrote:

...

The question if the package will ever make it to community - most people won't have community-testing enabled. It's not very typical for new packages that weren't in the repositories before. My guess it was because an alpha version was packaged, which shouldn't have been packaged in the repos in the first place.

Alad

I'm the packager for pijul (in community).

There's a decent chunk of packages in community that have alpha/beta releases so I assumed it was OK. Apologies if this is not the case.

It's not *actively monitored*, but this is really not supposed to happen... sometimes it does happen anyway if the current version is very buggy and currently breaking people's systems, upstream is not tagging a new release any time soon, and using an alpha/beta will improve the state of affairs, but that's pretty different from uploading a brand new package as an alpha, and one that nothing else depends on even. e.g. a notable one that I'm aware of is qt5-webkit which unfortunately is not very well maintained by Qt and the alpha by annulen provides life support with e.g. various needed security fixes. -- Eli Schwartz Bug Wrangler and Trusted User

On 01/07/2021 14:34, Morten Linderud via aur-general wrote:

On Wed, Jun 30, 2021 at 09:52:54PM -0400, Eli Schwartz via aur-general wrote:

...

On 6/30/21 9:35 PM, George Rawlinson via aur-general wrote:

...

On 21-06-30 15:05, alad via aur-general wrote:

...

The question if the package will ever make it to community - most people won't have community-testing enabled. It's not very typical for new packages that weren't in the repositories before. My guess it was because an alpha version was packaged, which shouldn't have been packaged in the repos in the first place.

Alad

I'm the packager for pijul (in community).

There's a decent chunk of packages in community that have alpha/beta releases so I assumed it was OK. Apologies if this is not the case. e.g. a notable one that I'm aware of is qt5-webkit which unfortunately is not very well maintained by Qt and the alpha by annulen provides life support with e.g. various needed security fixes. runc, which the entire container ecosystem has been depending on the past 7 years, got it's first stable release last week after almost 100 release candidates :) As summarized by eschwartz, the guidelines [1] clearly point out that:

Stable packages package stable releases: Release candidates (i.e. 1.0.0-rc1), alpha (e.g. 1.0.0-alpha1) and beta (e.g. 1.0.0-beta1) releases are not allowed and are only to be used under the following circumstances:

* The non-stable release holds urgent security fixes (and backporting is non-trivial). * The non-stable release allows for the package to be built (e.g. problems introduced due to updated dependencies) and those changes can not otherwise be backported easily. * The non-stable release allows the distribution to drop an EOL component (e.g. qt4, python2).

Apparently personal preference goes above the package guidelines. So remind me why we have them in the first place? Alad [1] https://wiki.archlinux.org/title/Arch_package_guidelines#Package_versioning

On 02/07/2021 01:35, Eli Schwartz via aur-general wrote:

On 7/1/21 8:34 AM, Morten Linderud via aur-general wrote:

...

runc, which the entire container ecosystem has been depending on the past 7 years, got it's first stable release last week after almost 100 release candidates :)

The very first version of runc in the official repos was 0.1.0, not 0.1.0alpha1 or anything of the sort.

The point is that the official repos had 13 times an 1.0.0rc for runc. Alad

Many projects get packaged and relied upon in a stable manner for a long time before hitting their 1.0 milestone releases, and this is completely fine. I've packaged a bunch of them myself too.

This is completely unrelated to any version of any software that states that it's an alpha edition of e.g. "1.0.0". Typical practice is to package 0.9.x or whatever, not 1.0.0 alpha48, since the former, despite being pre-1.0, is still denoting a more stable version than "alpha48".