[aur-general] Clarification for Deletion request #30701

silentnoodle

17 Dec 2021 17 Dec '21

12:05 a.m.

hey all, Today a package i co maintain (telegram-desktop-bin) was deleted because "Package exists in official community repo", but since we used prebuilt binary as source I did not think that would have applied. So guess I'd just like a word on what the first point in the rules of submission means: https://wiki.archlinux.org/title/AUR_submission_guidelines#Rules_of_submissi... Cheers, Ben a.k.a silentnoodle

Show replies by date

Justin Kromlinger

17 Dec 17 Dec

12:17 a.m.

On Fri, 17 Dec 2021 01:05:19 +0200 silentnoodle via aur-general wrote:

...

hey all,

Today a package i co maintain (telegram-desktop-bin) was deleted because "Package exists in official community repo", but since we used prebuilt binary as source I did not think that would have applied.

So guess I'd just like a word on what the first point in the rules of submission means: https://wiki.archlinux.org/title/AUR_submission_guidelines#Rules_of_submissi...

Cheers, Ben a.k.a silentnoodle

So basically: * telegram-desktop in community is git release 3.3.0 build by Arch Maintainers * telegram-desktop-bin in AUR is git release 3.3.0 build by upstream For the end user, those two are basically the same package. Therefore the AUR package is a duplicate. -- hashworks Web https://hashworks.net Public Key 0x4FE7F4FEAC8EBE67

Filipe Laíns

10:54 a.m.

On Fri, 2021-12-17 at 00:17 +0100, Justin Kromlinger via aur-general wrote:

...

On Fri, 17 Dec 2021 01:05:19 +0200 silentnoodle via aur-general wrote:

...
hey all,

Today a package i co maintain (telegram-desktop-bin) was deleted because "Package exists in official community repo", but since we used prebuilt binary as source I did not think that would have applied.

So guess I'd just like a word on what the first point in the rules of submission means: https://wiki.archlinux.org/title/AUR_submission_guidelines#Rules_of_submissi...

Cheers, Ben a.k.a silentnoodle

So basically: * telegram-desktop in community is git release 3.3.0 build by Arch Maintainers * telegram-desktop-bin in AUR is git release 3.3.0 build by upstream

For the end user, those two are basically the same package. Therefore the AUR package is a duplicate.

No, they aren't. I haven't looked into the request but if this is indeed the case, the package was incorrectly deleted. Cheers, Filipe Laíns

Bjoern Bidar

11:18 a.m.

...

On Fri, 2021-12-17 at 00:17 +0100, Justin Kromlinger via aur-general wrote:

...
On Fri, 17 Dec 2021 01:05:19 +0200

silentnoodle via aur-general wrote:

...
hey all,

Today a package i co maintain (telegram-desktop-bin) was deleted because "Package exists in official community repo", but since we used prebuilt binary as source I did not think that would have applied.

So guess I'd just like a word on what the first point in the rules of submission means: https://wiki.archlinux.org/title/AUR_submission_guidelines#Rules_of_subm ission

Cheers, Ben a.k.a silentnoodle

So basically: * telegram-desktop in community is git release 3.3.0 build by Arch Maintainers * telegram-desktop-bin in AUR is git release 3.3.0 build by upstream

For the end user, those two are basically the same package. Therefore the AUR package is a duplicate.

No, they aren't. I haven't looked into the request but if this is indeed the case, the package was incorrectly deleted. They package name indicates that both are the same but the other one is the prebulid by aur conventions. IMHO the prebuild made by upstream should have a packagename that indicates this.

Br, Björn

Mikhail f. Shiryaev

11:50 a.m.

On Fri, 17 Dec 2021, 11:20 Bjoern Bidar via aur-general, < aur-general@lists.archlinux.org> wrote:

...

...
...
On Fri, 17 Dec 2021 01:05:19 +0200

silentnoodle via aur-general wrote:

...
hey all,

Today a package i co maintain (telegram-desktop-bin) was deleted because "Package exists in official community repo", but since we used

...
...
binary as source I did not think that would have applied.

So guess I'd just like a word on what the first point in the rules of submission means:

https://wiki.archlinux.org/title/AUR_submission_guidelines#Rules_of_subm

...
ission

Cheers, Ben a.k.a silentnoodle

So basically: * telegram-desktop in community is git release 3.3.0 build by Arch Maintainers * telegram-desktop-bin in AUR is git release 3.3.0 build by upstream

For the end user, those two are basically the same package. Therefore

On Fri, 2021-12-17 at 00:17 +0100, Justin Kromlinger via aur-general wrote: prebuilt the

...
AUR package is a duplicate.

No, they aren't. I haven't looked into the request but if this is indeed the case, the package was incorrectly deleted. They package name indicates that both are the same but the other one is the prebulid by aur conventions. IMHO the prebuild made by upstream should have a packagename that indicates this.

Br,

Björn

Hello. Kind, but strong objections here. As I reported in https://bugs.archlinux.org/task/72749, many arch built QT applications are affected by a strange bug, and the community package telegram-desktop as well. But official static telegram binary is not. So it is at least not the same. And even better, it works for me. I don't get the recent movement "let's delete static binary packages", but it goes quite far. There are differences between community packages with shared libraries and static official builds. Kind regards, Mikhail f. Shiryaev

Brett Cornwall

4:01 p.m.

On 2021-12-17 09:54, Filipe Laíns via aur-general wrote:

...

On Fri, 2021-12-17 at 00:17 +0100, Justin Kromlinger via aur-general wrote:

...
On Fri, 17 Dec 2021 01:05:19 +0200 silentnoodle via aur-general wrote:

...
hey all,

Today a package i co maintain (telegram-desktop-bin) was deleted because "Package exists in official community repo", but since we used prebuilt binary as source I did not think that would have applied.

So guess I'd just like a word on what the first point in the rules of submission means: https://wiki.archlinux.org/title/AUR_submission_guidelines#Rules_of_submissi...

Cheers, Ben a.k.a silentnoodle

So basically: * telegram-desktop in community is git release 3.3.0 build by Arch Maintainers * telegram-desktop-bin in AUR is git release 3.3.0 build by upstream

For the end user, those two are basically the same package. Therefore the AUR package is a duplicate.

No, they aren't. I haven't looked into the request but if this is indeed the case, the package was incorrectly deleted.

From the rules of submission [1]:

...

The submitted PKGBUILDs must not build applications already in any of the official binary repositories under any circumstances. Check the official package database for the package. If any version of it exists, do not submit the package. If the official package is out-of-date, flag it as such. If the official package is broken or is lacking a feature, then please file a bug report.

...

Exception to this strict rule may only be packages having extra features enabled and/or patches in comparison to the official ones. In such an occasion the pkgname should be different to express that difference. For example, a package for GNU screen containing the sidebar patch could be named screen-sidebar. Additionally the provides=('screen') array should be used in order to avoid conflicts with the official package.

Submitting a package that is only different from the technicality that someone else built it is not enough to warrant its own package. If there's an issue with the telegram package in the repos, users should submit a bug report. As it stands, there was nothing notated in the package to suggest that it was anything but an upstream binary, so that was why I deleted it. [1] https://wiki.archlinux.org/title/AUR_submission_guidelines#Rules_of_submissi...

Xyne

18 Dec 18 Dec

7:32 p.m.

On 2021-12-17 07:01 -0800 Brett Cornwall via aur-general wrote:

...

Submitting a package that is only different from the technicality that someone else built it is not enough to warrant its own package. If there's an issue with the telegram package in the repos, users should submit a bug report.

As it stands, there was nothing notated in the package to suggest that it was anything but an upstream binary, so that was why I deleted it.

[1] https://wiki.archlinux.org/title/AUR_submission_guidelines#Rules_of_submissi...

The -bin prefix is used for packages that package upstream binaries but the assumption is typically that the resulting package is functionally equivalent to the one built on Arch from source. That is why our policy is to delete -bin package variants of binary packages in the official repos. In this case, the upstream binaries are not functionally equivalent because they are statically compiled and thus avoid a bug. They should be allowed on the AUR, but the prefix should be something to indicate that it is not just a -bin variant of the official package. Perhaps -static-bin would be appropriate. The real solution is though is to fix the packages in the repos.

Xyne

7:40 p.m.

...

The -bin prefix is used for packages that package upstream binaries but the assumption is typically that the resulting package is functionally equivalent to the one built on Arch from source. That is why our policy is to delete -bin package variants of binary packages in the official repos.

In this case, the upstream binaries are not functionally equivalent because they are statically compiled and thus avoid a bug. They should be allowed on the AUR, but the prefix should be something to indicate that it is not just a -bin variant of the official package. Perhaps -static-bin would be appropriate.

The real solution is though is to fix the packages in the repos.

Sorry, I was in a rush. That should have been "statically linked", and "suffix". Regards, Xyne

Radislav Golubtsov

8:40 p.m.

...

Sorry, I was in a rush. That should have been "statically linked", and "suffix". Hi "white spirit" guys, In those uncertain situations, like that one, I'm expectedly (personally) waiting for a clarification of one of our solid and stoick devvers — Xyne, Levente, Morten, ... You guys, you may have to bring out a ray of light on those or similar kind of debating. -- Kind regards, Radislav (Radicchio) Golubtsov (Sent from myMail for Android) Saturday, 18 December 2021, 09:40PM +03:00 from Xyne via aur-general aur-general@lists.archlinux.org :

...

The -bin prefix is used for packages that package upstream binaries but the assumption is typically that the resulting package is functionally equivalent to the one built on Arch from source. That is why our policy is to delete -bin package variants of binary packages in the official repos.

In this case, the upstream binaries are not functionally equivalent because they are statically compiled and thus avoid a bug. They should be allowed on the AUR, but the prefix should be something to indicate that it is not just a -bin variant of the official package. Perhaps -static-bin would be appropriate.

The real solution is though is to fix the packages in the repos.

Sorry, I was in a rush. That should have been "statically linked", and "suffix".

Regards, Xyne

alad

27 Dec 27 Dec

11:26 p.m.

On Fri, 17 Dec 2021 07:01:08 -0800 Brett Cornwall via aur-general wrote:

...

On 2021-12-17 09:54, Filipe Laíns via aur-general wrote:

...
On Fri, 2021-12-17 at 00:17 +0100, Justin Kromlinger via aur-general wrote:

...
On Fri, 17 Dec 2021 01:05:19 +0200 silentnoodle via aur-general wrote:

...
hey all,

Today a package i co maintain (telegram-desktop-bin) was deleted because "Package exists in official community repo", but since we used prebuilt binary as source I did not think that would have applied.

So guess I'd just like a word on what the first point in the rules of submission means: https://wiki.archlinux.org/title/AUR_submission_guidelines#Rules_of_submissi...

Cheers, Ben a.k.a silentnoodle

So basically: * telegram-desktop in community is git release 3.3.0 build by Arch Maintainers * telegram-desktop-bin in AUR is git release 3.3.0 build by upstream

For the end user, those two are basically the same package. Therefore the AUR package is a duplicate.

No, they aren't. I haven't looked into the request but if this is indeed the case, the package was incorrectly deleted.

From the rules of submission [1]:

...
The submitted PKGBUILDs must not build applications already in any of the official binary repositories under any circumstances. Check the official package database for the package. If any version of it exists, do not submit the package. If the official package is out-of-date, flag it as such. If the official package is broken or is lacking a feature, then please file a bug report.

...
Exception to this strict rule may only be packages having extra features enabled and/or patches in comparison to the official ones. In such an occasion the pkgname should be different to express that difference. For example, a package for GNU screen containing the sidebar patch could be named screen-sidebar. Additionally the provides=('screen') array should be used in order to avoid conflicts with the official package.

Submitting a package that is only different from the technicality that someone else built it is not enough to warrant its own package. If there's an issue with the telegram package in the repos, users should submit a bug report.

As it stands, there was nothing notated in the package to suggest that it was anything but an upstream binary, so that was why I deleted it.

[1] https://wiki.archlinux.org/title/AUR_submission_guidelines#Rules_of_submissi...

The upstream build is vastly different from the repos. Besides lacking bugs in the downstream version, it only has a fraction of the dependencies (i.e. no pipewire). As such I see no valid reason for the deletion. Alad -- alad

Brett Cornwall

28 Dec 28 Dec

12:06 a.m.

On 2021-12-27 23:26, alad via aur-general wrote:

...

On Fri, 17 Dec 2021 07:01:08 -0800 Brett Cornwall via aur-general wrote:

...
On 2021-12-17 09:54, Filipe Laíns via aur-general wrote:

...
On Fri, 2021-12-17 at 00:17 +0100, Justin Kromlinger via aur-general wrote:

...
On Fri, 17 Dec 2021 01:05:19 +0200 silentnoodle via aur-general wrote:

...
hey all,

Today a package i co maintain (telegram-desktop-bin) was deleted because "Package exists in official community repo", but since we used prebuilt binary as source I did not think that would have applied.

So guess I'd just like a word on what the first point in the rules of submission means: https://wiki.archlinux.org/title/AUR_submission_guidelines#Rules_of_submissi...

Cheers, Ben a.k.a silentnoodle

So basically: * telegram-desktop in community is git release 3.3.0 build by Arch Maintainers * telegram-desktop-bin in AUR is git release 3.3.0 build by upstream

For the end user, those two are basically the same package. Therefore the AUR package is a duplicate.

No, they aren't. I haven't looked into the request but if this is indeed the case, the package was incorrectly deleted.

From the rules of submission [1]:

...
The submitted PKGBUILDs must not build applications already in any of the official binary repositories under any circumstances. Check the official package database for the package. If any version of it exists, do not submit the package. If the official package is out-of-date, flag it as such. If the official package is broken or is lacking a feature, then please file a bug report.

...
Exception to this strict rule may only be packages having extra features enabled and/or patches in comparison to the official ones. In such an occasion the pkgname should be different to express that difference. For example, a package for GNU screen containing the sidebar patch could be named screen-sidebar. Additionally the provides=('screen') array should be used in order to avoid conflicts with the official package.

Submitting a package that is only different from the technicality that someone else built it is not enough to warrant its own package. If there's an issue with the telegram package in the repos, users should submit a bug report.

As it stands, there was nothing notated in the package to suggest that it was anything but an upstream binary, so that was why I deleted it.

[1] https://wiki.archlinux.org/title/AUR_submission_guidelines#Rules_of_submissi...

The upstream build is vastly different from the repos. Besides lacking bugs in the downstream version, it only has a fraction of the dependencies (i.e. no pipewire). As such I see no valid reason for the deletion.

And how am I supposed to have known that? It sounds like someone could merely make e.g. telegram-no-pipewire package that builds with the respective flags. Is "it's built by upstream" reason enough to break the rules of submission quoted above? More broadly, are we to allow all upstream binaries to be packaged? If so, can we designate a different suffix than -bin so that I don't draw ire when I dare accept the removal request of a package with no difference in denotation than the in-repo packages? Or can we get in writing the acceptance of AUR packages of "upstream" releases alongside our own official packages? As it stands, I am getting feedback both ways: One side is in agreement with me that -bin packages needn't exist and that no, "but it's upstream" is not a valid reason. But the other side screams loudly when *their* favorite upstream package is removed in accordance to that (and never any other time).

alad

3:35 p.m.

On Mon, 27 Dec 2021 15:06:44 -0800 Brett Cornwall wrote:

...

On 2021-12-27 23:26, alad via aur-general wrote:

...
On Fri, 17 Dec 2021 07:01:08 -0800 Brett Cornwall via aur-general wrote:

...
On 2021-12-17 09:54, Filipe Laíns via aur-general wrote:

...
On Fri, 2021-12-17 at 00:17 +0100, Justin Kromlinger via aur-general wrote:

...
On Fri, 17 Dec 2021 01:05:19 +0200 silentnoodle via aur-general wrote:

...
hey all,

Today a package i co maintain (telegram-desktop-bin) was deleted because "Package exists in official community repo", but since we used prebuilt binary as source I did not think that would have applied.

So guess I'd just like a word on what the first point in the rules of submission means: https://wiki.archlinux.org/title/AUR_submission_guidelines#Rules_of_submissi...

Cheers, Ben a.k.a silentnoodle

So basically: * telegram-desktop in community is git release 3.3.0 build by Arch Maintainers * telegram-desktop-bin in AUR is git release 3.3.0 build by upstream

For the end user, those two are basically the same package. Therefore the AUR package is a duplicate.

No, they aren't. I haven't looked into the request but if this is indeed the case, the package was incorrectly deleted.

From the rules of submission [1]:

...
The submitted PKGBUILDs must not build applications already in any of the official binary repositories under any circumstances. Check the official package database for the package. If any version of it exists, do not submit the package. If the official package is out-of-date, flag it as such. If the official package is broken or is lacking a feature, then please file a bug report.

...
Exception to this strict rule may only be packages having extra features enabled and/or patches in comparison to the official ones. In such an occasion the pkgname should be different to express that difference. For example, a package for GNU screen containing the sidebar patch could be named screen-sidebar. Additionally the provides=('screen') array should be used in order to avoid conflicts with the official package.

Submitting a package that is only different from the technicality that someone else built it is not enough to warrant its own package. If there's an issue with the telegram package in the repos, users should submit a bug report.

As it stands, there was nothing notated in the package to suggest that it was anything but an upstream binary, so that was why I deleted it.

[1] https://wiki.archlinux.org/title/AUR_submission_guidelines#Rules_of_submissi...

The upstream build is vastly different from the repos. Besides lacking bugs in the downstream version, it only has a fraction of the dependencies (i.e. no pipewire). As such I see no valid reason for the deletion.

And how am I supposed to have known that?

By looking at how the packages differ before simply accepting the request?

...

It sounds like someone could merely make e.g. telegram-no-pipewire package that builds with the respective flags. Is "it's built by upstream" reason enough to break the rules of submission quoted above?

More broadly, are we to allow all upstream binaries to be packaged? If so, can we designate a different suffix than -bin so that I don't draw ire when I dare accept the removal request of a package with no difference in denotation than the in-repo packages? Or can we get in writing the acceptance of AUR packages of "upstream" releases alongside our own official packages?

As it stands, I am getting feedback both ways: One side is in agreement with me that -bin packages needn't exist and that no, "but it's upstream" is not a valid reason. But the other side screams loudly when *their* favorite upstream package is removed in accordance to that (and never any other time).

I am general disagreement of people widely removing packages from the AUR, merely because it is an upstream build (built on different machines, with different purposes). Even popular packages like firefox-bin have been deleted because of this. If a different suffix will avoid these kind of knee-jerk responses, I'm all for it. -- alad

Brett Cornwall

6:21 p.m.

On 2021-12-28 15:35, alad wrote:

...

...
And how am I supposed to have known that?

By looking at how the packages differ before simply accepting the request?

I'm not going to compare binaries for each -bin request in the hopes that there's some difference that makes it worthwhile to keep. It's the packager's job to describe what the package's use is; That's what the description field is for. telegram-desktop-bin's *only* message was that it was built by upstream and nothing more. Again, if someone wants that package without the deps, telegram-no-pipewire or telegram-minimal is a better option.

...

...
It sounds like someone could merely make e.g. telegram-no-pipewire package that builds with the respective flags. Is "it's built by upstream" reason enough to break the rules of submission quoted above?

More broadly, are we to allow all upstream binaries to be packaged? If so, can we designate a different suffix than -bin so that I don't draw ire when I dare accept the removal request of a package with no difference in denotation than the in-repo packages? Or can we get in writing the acceptance of AUR packages of "upstream" releases alongside our own official packages?

As it stands, I am getting feedback both ways: One side is in agreement with me that -bin packages needn't exist and that no, "but it's upstream" is not a valid reason. But the other side screams loudly when *their* favorite upstream package is removed in accordance to that (and never any other time).

I am general disagreement of people widely removing packages from the AUR, merely because it is an upstream build (built on different machines, with different purposes). Even popular packages like firefox-bin have been deleted because of this.

If a different suffix will avoid these kind of knee-jerk responses, I'm all for it.

Feel free to post an RFC. In the meantime, I'll continue to follow the rules that have been established.

Aleksandar Trifunovic

7:07 p.m.

On Tue, Dec 28, 2021 at 6:21 PM Brett Cornwall via aur-general wrote:

...

On 2021-12-28 15:35, alad wrote:

...
...
And how am I supposed to have known that?

By looking at how the packages differ before simply accepting the request?

I'm not going to compare binaries for each -bin request in the hopes that there's some difference that makes it worthwhile to keep. It's the packager's job to describe what the package's use is; That's what the description field is for. telegram-desktop-bin's *only* message was that it was built by upstream and nothing more.

Following the list I get an impression that "built by upstream" == "packaged by arch". However these packages are practically *always* different if the developers are not using/targeting archlinux as primary distro. For example cura package was broken in Arch under KDE (maybe still is) but the cura-appimage-bin package that is "built by upstream" works.

...

Again, if someone wants that package without the deps, telegram-no-pipewire or telegram-minimal is a better option.

...
...
It sounds like someone could merely make e.g. telegram-no-pipewire package that builds with the respective flags. Is "it's built by upstream" reason enough to break the rules of submission quoted above?

More broadly, are we to allow all upstream binaries to be packaged? If so, can we designate a different suffix than -bin so that I don't draw ire when I dare accept the removal request of a package with no difference in denotation than the in-repo packages? Or can we get in writing the acceptance of AUR packages of "upstream" releases alongside our own official packages?

As it stands, I am getting feedback both ways: One side is in agreement with me that -bin packages needn't exist and that no, "but it's upstream" is not a valid reason. But the other side screams loudly when *their* favorite upstream package is removed in accordance to that (and never any other time).

I am general disagreement of people widely removing packages from the AUR, merely because it is an upstream build (built on different machines, with different purposes). Even popular packages like firefox-bin have been deleted because of this.

If a different suffix will avoid these kind of knee-jerk responses, I'm all for it.

Feel free to post an RFC. In the meantime, I'll continue to follow the rules that have been established.

Some rules don't make sense. Arch's reality is that the libraries will often be newer than the ones the upstream is using for the development which can cause subtle bugs. AUR packages that just repackage upstream bin files have worked for me on numerous occasions when Arch packages break. Sure I can download the bin package and use it however its nice to have it managed with pacman. Best, Aleks

Brett Cornwall

7:45 p.m.

On 2021-12-28 19:07, Aleksandar Trifunovic via aur-general wrote:

...

On Tue, Dec 28, 2021 at 6:21 PM Brett Cornwall via aur-general wrote:

...
On 2021-12-28 15:35, alad wrote:

...
...
And how am I supposed to have known that?

By looking at how the packages differ before simply accepting the request?

I'm not going to compare binaries for each -bin request in the hopes that there's some difference that makes it worthwhile to keep. It's the packager's job to describe what the package's use is; That's what the description field is for. telegram-desktop-bin's *only* message was that it was built by upstream and nothing more.

Following the list I get an impression that "built by upstream" == "packaged by arch". However these packages are practically *always* different if the developers are not using/targeting archlinux as primary distro. For example cura package was broken in Arch under KDE (maybe still is) but the cura-appimage-bin package that is "built by upstream" works.

Sounds like a good opportunity to file some bug reports.

...

...
Again, if someone wants that package without the deps, telegram-no-pipewire or telegram-minimal is a better option.

...
...
It sounds like someone could merely make e.g. telegram-no-pipewire package that builds with the respective flags. Is "it's built by upstream" reason enough to break the rules of submission quoted above?

More broadly, are we to allow all upstream binaries to be packaged? If so, can we designate a different suffix than -bin so that I don't draw ire when I dare accept the removal request of a package with no difference in denotation than the in-repo packages? Or can we get in writing the acceptance of AUR packages of "upstream" releases alongside our own official packages?

As it stands, I am getting feedback both ways: One side is in agreement with me that -bin packages needn't exist and that no, "but it's upstream" is not a valid reason. But the other side screams loudly when *their* favorite upstream package is removed in accordance to that (and never any other time).

I am general disagreement of people widely removing packages from the AUR, merely because it is an upstream build (built on different machines, with different purposes). Even popular packages like firefox-bin have been deleted because of this.

If a different suffix will avoid these kind of knee-jerk responses, I'm all for it.

Feel free to post an RFC. In the meantime, I'll continue to follow the rules that have been established.

Some rules don't make sense.

That's what the RFC process is for.

...

Arch's reality is that the libraries will often be newer than the ones the upstream is using for the development which can cause subtle bugs.

AUR packages that just repackage upstream bin files have worked for me on numerous occasions when Arch packages break. Sure I can download the bin package and use it however its nice to have it managed with pacman.

Consider using a different distribution if the concept of a central package manager does not serve you. This distribution does not cater to user convenience; it caters to technical correctness and pragmatism. I do not accept that containing upstream AUR packages to mirror the entire repository of Arch is pragmatic or even helpful. If a package is not working for you, the expectation is that you will notify the package maintainer of any package-specific bugs or upstream if it's a general bug.

Aleksandar Trifunovic

9:18 p.m.

On Tue, Dec 28, 2021 at 7:46 PM Brett Cornwall via aur-general wrote:

...

On 2021-12-28 19:07, Aleksandar Trifunovic via aur-general wrote:

...
On Tue, Dec 28, 2021 at 6:21 PM Brett Cornwall via aur-general wrote:

...
On 2021-12-28 15:35, alad wrote:

...
...
And how am I supposed to have known that?

By looking at how the packages differ before simply accepting the request?

I'm not going to compare binaries for each -bin request in the hopes that there's some difference that makes it worthwhile to keep. It's the packager's job to describe what the package's use is; That's what the description field is for. telegram-desktop-bin's *only* message was that it was built by upstream and nothing more.

Following the list I get an impression that "built by upstream" == "packaged by arch". However these packages are practically *always* different if the developers are not using/targeting archlinux as primary distro. For example cura package was broken in Arch under KDE (maybe still is) but the cura-appimage-bin package that is "built by upstream" works.

Sounds like a good opportunity to file some bug reports.

...
...
Again, if someone wants that package without the deps, telegram-no-pipewire or telegram-minimal is a better option.

...
...
It sounds like someone could merely make e.g. telegram-no-pipewire package that builds with the respective flags. Is "it's built by upstream" reason enough to break the rules of submission quoted above?

More broadly, are we to allow all upstream binaries to be packaged? If so, can we designate a different suffix than -bin so that I don't draw ire when I dare accept the removal request of a package with no difference in denotation than the in-repo packages? Or can we get in writing the acceptance of AUR packages of "upstream" releases alongside our own official packages?

As it stands, I am getting feedback both ways: One side is in agreement with me that -bin packages needn't exist and that no, "but it's upstream" is not a valid reason. But the other side screams loudly when *their* favorite upstream package is removed in accordance to that (and never any other time).

I am general disagreement of people widely removing packages from the AUR, merely because it is an upstream build (built on different machines, with different purposes). Even popular packages like firefox-bin have been deleted because of this.

If a different suffix will avoid these kind of knee-jerk responses, I'm all for it.

Feel free to post an RFC. In the meantime, I'll continue to follow the rules that have been established.

Some rules don't make sense.

That's what the RFC process is for.

...
Arch's reality is that the libraries will often be newer than the ones the upstream is using for the development which can cause subtle bugs.

AUR packages that just repackage upstream bin files have worked for me on numerous occasions when Arch packages break. Sure I can download the bin package and use it however its nice to have it managed with pacman.

Consider using a different distribution if the concept of a central package manager does not serve you. This distribution does not cater to user convenience; it caters to technical correctness and pragmatism.

What does a central package management have to do with this discussion? It is pragmatic that you go around and delete files just because you like to waste your time and time of other people? Sounds like you don't understand the word pragmatic. Also a package that works (upstream binary) is technically correct and repackaging done with newer libraries is less likely to be technically correct so I have no idea what you are talking about. This is something that should be widespread knowledge and accepted shortcoming of the distribution model and not argued like its perfect.

...

I do not accept that containing upstream AUR packages to mirror the entire repository of Arch is pragmatic or even helpful.

It is many times repeated that majority of these packages are not the same.

...

If a package is not working for you, the expectation is that you will notify the package maintainer of any package-specific bugs or upstream if it's a general bug.

I do that and/or try to fix it as well if possible and? Reporting a bug does not change the fact that the package is broken *now* and sometimes cant be fixed for a while. Aleks

Doug Newgard

7:08 p.m.

On Tue, 28 Dec 2021 09:21:01 -0800 Brett Cornwall via aur-general wrote:

...

Feel free to post an RFC. In the meantime, I'll continue to follow the rules that have been established.

Established where? Upstream builds as -bin packages were fine in the AUR for years, it's only recently that a couple of TUs have decided to disallow it.

Brett Cornwall

7:34 p.m.

On 2021-12-28 12:08, Doug Newgard via aur-general wrote:

...

On Tue, 28 Dec 2021 09:21:01 -0800 Brett Cornwall via aur-general wrote:

...
Feel free to post an RFC. In the meantime, I'll continue to follow the rules that have been established.

Established where? Upstream builds as -bin packages were fine in the AUR for years, it's only recently that a couple of TUs have decided to disallow it.

Established in the AUR submission guidelines [1], which has been quoted thrice now:

...

The submitted PKGBUILDs must not build applications already in any of the official binary repositories under any circumstances. Check the official package database for the package. If any version of it exists, do not submit the package. If the official package is out-of-date, flag it as such. If the official package is broken or is lacking a feature, then please file a bug report.

I don't care about what we do, so long as it's consistent with our rules. Saying "it's always been this way" is an appeal to tradition and is not helpful as an argument. So yes, an RFC/change in how our *rules* say we should behave would be the correct way forward instead of having three different interpretations of what we currently have. [1] https://wiki.archlinux.org/title/AUR_submission_guidelines#Rules_of_submissi...

Doug Newgard

8:17 p.m.

On Tue, 28 Dec 2021 10:34:58 -0800 Brett Cornwall via aur-general wrote:

...

On 2021-12-28 12:08, Doug Newgard via aur-general wrote:

...
On Tue, 28 Dec 2021 09:21:01 -0800 Brett Cornwall via aur-general wrote:

...
Feel free to post an RFC. In the meantime, I'll continue to follow the rules that have been established.

Established where? Upstream builds as -bin packages were fine in the AUR for years, it's only recently that a couple of TUs have decided to disallow it.

Established in the AUR submission guidelines [1], which has been quoted thrice now:

...
The submitted PKGBUILDs must not build applications already in any of the official binary repositories under any circumstances. Check the official package database for the package. If any version of it exists, do not submit the package. If the official package is out-of-date, flag it as such. If the official package is broken or is lacking a feature, then please file a bug report.

The point of this section is to prevent people from uploading updated version of repo PKBGUILDs because they're impatient. That's why it specifically talks about that. You may interpret it differently, but that's not how it was meant or how it has been done in the past. You'll also note that it gives exceptions for software that's build differently, different options/libs/etc. That would easily cover this case, as upstream will NOT be building it the same way as Arch.

...

I don't care about what we do, so long as it's consistent with our rules. Saying "it's always been this way" is an appeal to tradition and is not helpful as an argument.

So yes, an RFC/change in how our *rules* say we should behave would be the correct way forward instead of having three different interpretations of what we currently have.

[1] https://wiki.archlinux.org/title/AUR_submission_guidelines#Rules_of_submissi...

Brett Cornwall

8:59 p.m.

On 2021-12-28 13:17, Doug Newgard via aur-general wrote:

...

On Tue, 28 Dec 2021 10:34:58 -0800 Brett Cornwall via aur-general wrote:

...
On 2021-12-28 12:08, Doug Newgard via aur-general wrote:

...
On Tue, 28 Dec 2021 09:21:01 -0800 Brett Cornwall via aur-general wrote:

...
Feel free to post an RFC. In the meantime, I'll continue to follow the rules that have been established.

Established where? Upstream builds as -bin packages were fine in the AUR for years, it's only recently that a couple of TUs have decided to disallow it.

Established in the AUR submission guidelines [1], which has been quoted thrice now:

...
The submitted PKGBUILDs must not build applications already in any of the official binary repositories under any circumstances. Check the official package database for the package. If any version of it exists, do not submit the package. If the official package is out-of-date, flag it as such. If the official package is broken or is lacking a feature, then please file a bug report.

The point of this section is to prevent people from uploading updated version of repo PKBGUILDs because they're impatient. That's why it specifically talks about that. You may interpret it differently, but that's not how it was meant or how it has been done in the past.

You'll also note that it gives exceptions for software that's build differently, different options/libs/etc. That would easily cover this case, as upstream will NOT be building it the same way as Arch.

Ah, cool, so we can have infinite different builds of software already released in the official repos because they're technically built for different distribution methods? -bin, -appimage-bin, -flatpak-bin, -guix-bin, -docker-bin? Should we just do away with deletion requests entirely except for the illegal/malicious packages? Condoning the AUR as a literal dumping ground of binary distributions is fine (I guess) so long as we're on the same page. Clearly, I'm not the only one interpreting this "incorrectly" as these are not infrequent requests. So while we may be wrong it behooves us to update the Wiki to *explicitly allow* these kinds of packages. "Someone affiliated with the project built this for us" is not a valid feature to be an exception in my (and a few other TUs') opinions. Let's RFC this.

Manuel Reimer

7:31 p.m.

On 28.12.21 18:21, Brett Cornwall via aur-general wrote:

...

I'm not going to compare binaries for each -bin request in the hopes that there's some difference that makes it worthwhile to keep. It's the packager's job to describe what the package's use is; That's what the description field is for. telegram-desktop-bin's *only* message was that it was built by upstream and nothing more.

Again, if someone wants that package without the deps, telegram-no-pipewire or telegram-minimal is a better option.

But then please make it "telegram-no-pipewire-bin" so it is clearly visible that this is packaged from precompiled binaries. My expectation for a "telegram-no-pipewire" PKGBUILD would be that this is basically the official Arch PKGBUILD with slightly different configure params to drop dependencies the author for some reasons did not want to have. Manuel

eNV25

10:57 p.m.

On Fri, Dec 17, 2021 at 8:31 PM Brett Cornwall via aur-general wrote:

...

From the rules of submission [1]:

...
The submitted PKGBUILDs must not build applications already in any of the official binary repositories under any circumstances. Check the official package database for the package. If any version of it exists, do not submit the package. If the official package is out-of-date, flag it as such. If the official package is broken or is lacking a feature, then please file a bug report.

...
Exception to this strict rule may only be packages having extra features enabled and/or patches in comparison to the official ones. In such an occasion the pkgname should be different to express that difference. For example, a package for GNU screen containing the sidebar patch could be named screen-sidebar. Additionally the provides=('screen') array should be used in order to avoid conflicts with the official package.

Submitting a package that is only different from the technicality that someone else built it is not enough to warrant its own package. If there's an issue with the telegram package in the repos, users should submit a bug report.

As it stands, there was nothing notated in the package to suggest that it was anything but an upstream binary, so that was why I deleted it.

[1] https://wiki.archlinux.org/title/AUR_submission_guidelines#Rules_of_submissi...

So in this case the package would be fine if it had a different name, with a suffix like -upstream-bin, -official-bin or -static-bin?

Brett Cornwall

29 Dec 29 Dec

4:52 a.m.

On 2021-12-29 03:27, eNV25 via aur-general wrote:

...

So in this case the package would be fine if it had a different name, with a suffix like -upstream-bin, -official-bin or -static-bin?

I am working with the others to see what we want to establish going forward. Thanks for the patience.

Xyne

1 Jan 1 Jan

5:33 a.m.

On 2021-12-28 19:52 -0800 Brett Cornwall via aur-general wrote:

...

On 2021-12-29 03:27, eNV25 via aur-general wrote:

...
So in this case the package would be fine if it had a different name, with a suffix like -upstream-bin, -official-bin or -static-bin?

I am working with the others to see what we want to establish going forward. Thanks for the patience.

I hope that we all agree on the following rules: * All packages built from pre-compiled sources in the AUR should retain the "-bin" suffix to indicate this, without exception. * A package named <name>-bin should be functionally equivalent to one named <name> once built. * Package variants should use names that identify them, e.g. a statically pre-compiled variant of foo should be named foo-static-bin. The crux of the problem is which variants of official packages should be allowed in the AUR, if any. Pre-compiled packages from upstream that use different build options clearly have upstream support, and they avoid possibly lengthy compilations for users who wish to use those options. I think that they should be allowed. However, packages that build from source using different build options should not. The user can already obtain and modify the official PKGBUILD from ABS without the AUR. It would only clutter the AUR to allow all possible combinations of build options for every package, official or not. Users are expected to be able to modify a PKGBUILD to suit their needs. I therefore suggest that we allow correctly-named pre-compiled variants of official packages provided that the pre-compiled binaries are built by upstream, while still disallowing all other variants of official packages. Regards, Xyne And happy new year!

Brett Cornwall

6:40 a.m.

On 2022-01-01 05:33, Xyne via aur-general wrote:

...

On 2021-12-28 19:52 -0800 Brett Cornwall via aur-general wrote:

...
On 2021-12-29 03:27, eNV25 via aur-general wrote:

...
So in this case the package would be fine if it had a different name, with a suffix like -upstream-bin, -official-bin or -static-bin?

I am working with the others to see what we want to establish going forward. Thanks for the patience.

I hope that we all agree on the following rules:

* All packages built from pre-compiled sources in the AUR should retain the "-bin" suffix to indicate this, without exception.

* A package named <name>-bin should be functionally equivalent to one named <name> once built.

* Package variants should use names that identify them, e.g. a statically pre-compiled variant of foo should be named foo-static-bin.

The crux of the problem is which variants of official packages should be allowed in the AUR, if any. Pre-compiled packages from upstream that use different build options clearly have upstream support, and they avoid possibly lengthy compilations for users who wish to use those options. I think that they should be allowed.

However, packages that build from source using different build options should not. The user can already obtain and modify the official PKGBUILD from ABS without the AUR. It would only clutter the AUR to allow all possible combinations of build options for every package, official or not. Users are expected to be able to modify a PKGBUILD to suit their needs.

I therefore suggest that we allow correctly-named pre-compiled variants of official packages provided that the pre-compiled binaries are built by upstream, while still disallowing all other variants of official packages.

Regards, Xyne

And happy new year!

Would you be kind enough to post that to the thread I started over on aur-dev? (message ID <20211229050623.2jghonze56wi4fxe@faun>, subject "Packaging upstream binaries when we already have official releases") To me, it's important to have it in writing what we agree on so we don't have these issues again. Happy new year to you as well. :)

Doug Newgard

12:50 p.m.

On Fri, 31 Dec 2021 21:40:38 -0800 Brett Cornwall via aur-general wrote:

...

Would you be kind enough to post that to the thread I started over on aur-dev? (message ID <20211229050623.2jghonze56wi4fxe@faun>, subject "Packaging upstream binaries when we already have official releases")

To me, it's important to have it in writing what we agree on so we don't have these issues again.

Happy new year to you as well. :)

Why in the world would this be on aur-dev? This has nothing to do with development of the AUR, it's about Arch policy. All moving it to aur-dev does is hide it from the vast majority of people.

Doug Newgard

12:48 p.m.

On Sat, 1 Jan 2022 05:33:08 +0100 Xyne via aur-general wrote:

...

On 2021-12-28 19:52 -0800 Brett Cornwall via aur-general wrote:

...
On 2021-12-29 03:27, eNV25 via aur-general wrote:

...
So in this case the package would be fine if it had a different name, with a suffix like -upstream-bin, -official-bin or -static-bin?

I am working with the others to see what we want to establish going forward. Thanks for the patience.

I hope that we all agree on the following rules:

* All packages built from pre-compiled sources in the AUR should retain the "-bin" suffix to indicate this, without exception.

Packages that cannot be built from source have always been an exception here, are you proposing to eliminate that? It makes little sense to have a -bin package when there cannot be a non-bin version.

...

* A package named <name>-bin should be functionally equivalent to one named <name> once built.

* Package variants should use names that identify them, e.g. a statically pre-compiled variant of foo should be named foo-static-bin.

The crux of the problem is which variants of official packages should be allowed in the AUR, if any. Pre-compiled packages from upstream that use different build options clearly have upstream support, and they avoid possibly lengthy compilations for users who wish to use those options. I think that they should be allowed.

However, packages that build from source using different build options should not. The user can already obtain and modify the official PKGBUILD from ABS without the AUR. It would only clutter the AUR to allow all possible combinations of build options for every package, official or not. Users are expected to be able to modify a PKGBUILD to suit their needs.

This would eliminate almost all of the kernel packages in the AUR. Is that your intent?

...

I therefore suggest that we allow correctly-named pre-compiled variants of official packages provided that the pre-compiled binaries are built by upstream, while still disallowing all other variants of official packages.

Regards, Xyne

And happy new year!

Caleb Maclennan

7:24 p.m.

On 2022-01-01 14:48, Doug Newgard via aur-general wrote:

...

On Sat, 1 Jan 2022 05:33:08 +0100

...
* All packages built from pre-compiled sources in the AUR should retain the "-bin" suffix to indicate this, without exception.

Packages that cannot be built from source have always been an exception here, are you proposing to eliminate that? It makes little sense to have a -bin package when there cannot be a non-bin version.

Doug is right that there has always been an exception here. The rule to date as I've understood it is that the package must be suffixed with -bin if the source is available whether a package exists or not, but many closed source packages have been exceptions. That being said I would fully support a proposition to make this a requirement for *all* binary packages whether source is available or not. We should probably make that issue it's own thread because it really isn't the same issue as whether -bin packages should be deleted if repo builds are available. Caleb

Radislav Golubtsov

9 p.m.

...

Sunday, January 2, 2022 5:24 AM +11:00 from Caleb Maclennan via aur-general : On 2022-01-01 14:48, Doug Newgard via aur-general wrote:

...
On Sat, 1 Jan 2022 05:33:08 +0100

...
* All packages built from pre-compiled sources in the AUR should retain the "-bin" suffix to indicate this, without exception.

Packages that cannot be built from source have always been an exception here, are you proposing to eliminate that? It makes little sense to have a -bin package when there cannot be a non-bin version. Doug is right that there has always been an exception here. The rule to date as I've understood it is that the package must be suffixed with -bin if the source is available whether a package exists or not, but many closed source packages have been exceptions.

That being said I would fully support a proposition to make this a requirement for *all* binary packages whether source is available or not.

We should probably make that issue it's own thread because it really isn't the same issue as whether -bin packages should be deleted if repo builds are available.

Caleb Happy New Year guys! +1 to Doug and Caleb replies in a row. And solely from my side, apart of others, I’m interested in keeping skypeforlinux-stable-bin, besides other packages, in its current state. I’m not a maintainer, but simply an ordinary user of it. -- Kind regards, Radislav (Radicchio) Golubtsov Arch Linux and OpenBSD addict http://rgolubtsov.github.io/

Xyne

2 Jan 2 Jan

11:54 p.m.

On 2022-01-01 21:24 +0300 Caleb Maclennan via aur-general wrote:

...

On 2022-01-01 14:48, Doug Newgard via aur-general wrote:

...
On Sat, 1 Jan 2022 05:33:08 +0100

...
* All packages built from pre-compiled sources in the AUR should retain the "-bin" suffix to indicate this, without exception.

Packages that cannot be built from source have always been an exception here, are you proposing to eliminate that? It makes little sense to have a -bin package when there cannot be a non-bin version.

Doug is right that there has always been an exception here. The rule to date as I've understood it is that the package must be suffixed with -bin if the source is available whether a package exists or not, but many closed source packages have been exceptions.

That being said I would fully support a proposition to make this a requirement for *all* binary packages whether source is available or not.

We should probably make that issue it's own thread because it really isn't the same issue as whether -bin packages should be deleted if repo builds are available.

I actually would be in favor of using the -bin suffix even for packages without a non-bin variant. It makes the origin of the binaries clear to the user and may even draw further attention to the fact that upstream is not releasing buildable sources, which is something that we should at least gently encourage. It also avoids renaming packages if and when buildable sources become available. This is just my personal preference though and I admit that I had not considered the case when I replied. I'm not really opposed to the exception "unless source code is unavailable". I hadn't considered the kernel packages in the AUR either. On further consideration I really don't know what's best. Whatever rules we decide, the goal is to make the AUR as useful as possible. linux-ck and linux-mainline are clearly popular and thus useful so I do not propose removing them. But I still don't think that we should allow multiple variants of the same package that do nothing more than change a few build options. The difficulty is clearly defining the difference between a trivial modification and one that is involved enough that it is preferable to have a dedicated package. We could use popularity as a criterion for allowing a variant, but that requires some arbitrary thresholds of votes and time. Or we could just allow all variants. The important thing is that the rules are applied uniformly. Regards, Xyne

Ralf Mardorf

3 Jan 3 Jan

1:34 a.m.

Last March I increased my power bill, since from running makepkg to electron9-9.4.4-2-x86_64.pkg.tar.zst by building from source > 19 hours passed. If users need bloadware that is already available by official repositories, but they need another version or the same version with different build options, it's nice if a package from AUR provides a bin.

Jonathon Fernyhough

2:33 a.m.

On 02/01/2022 22:54, Xyne via aur-general wrote:

...

I actually would be in favor of using the -bin suffix even for packages without a non-bin variant.

I was under the impression that `-bin` was to be used for any pre-compiled version (e.g. whether sourced from upstream or from deb or RPM etc.)?

Doug Newgard

2:39 a.m.

On Mon, 3 Jan 2022 01:33:20 +0000 Jonathon Fernyhough via aur-general wrote:

...

On 02/01/2022 22:54, Xyne via aur-general wrote:

...
I actually would be in favor of using the -bin suffix even for packages without a non-bin variant.

I was under the impression that `-bin` was to be used for any pre-compiled version (e.g. whether sourced from upstream or from deb or RPM etc.)?

It's not about the source of the binaries, it's about proprietary software that does not, and can never, have a non-bin version. For example, steam in Community would need to be steam-bin as it's just repackaging upstream binaries.

Brett Cornwall

1 Jan 1 Jan

5:58 p.m.

On 2021-12-17 01:05, silentnoodle via aur-general wrote:

...

hey all,

Today a package i co maintain (telegram-desktop-bin) was deleted because "Package exists in official community repo", but since we used prebuilt binary as source I did not think that would have applied.

So guess I'd just like a word on what the first point in the rules of submission means: https://wiki.archlinux.org/title/AUR_submission_guidelines#Rules_of_submissi...

Cheers, Ben a.k.a silentnoodle

Hey, Ben. feel free to re-upload the package for now; this is unfortunately taking longer than I'd have hoped. Since there is value in this package to the community it makes no sense to keep it down while this process is afoot. Thanks for your patience.

Xyne

2 Jan 2 Jan

11:56 p.m.

On 2022-01-01 08:58 -0800 Brett Cornwall via aur-general wrote:

...

On 2021-12-17 01:05, silentnoodle via aur-general wrote:

...
hey all,

Today a package i co maintain (telegram-desktop-bin) was deleted because "Package exists in official community repo", but since we used prebuilt binary as source I did not think that would have applied.

So guess I'd just like a word on what the first point in the rules of submission means: https://wiki.archlinux.org/title/AUR_submission_guidelines#Rules_of_submissi...

Cheers, Ben a.k.a silentnoodle

Hey, Ben.

feel free to re-upload the package for now; this is unfortunately taking longer than I'd have hoped. Since there is value in this package to the community it makes no sense to keep it down while this process is afoot.

Thanks for your patience.

It it's statically linked, I suggest renaming it telegram-desktop-static-bin to make this clear. Regards, Xyne

841

Age (days ago)

859

Last active (days ago)

List overview

Download

34 comments

16 participants

participants (16)

alad
Aleksandar Trifunovic
Bjoern Bidar
Brett Cornwall
Caleb Maclennan
Doug Newgard
eNV25
Filipe Laíns
Jonathon Fernyhough
Justin Kromlinger
Manuel Reimer
Mikhail f. Shiryaev
Radislav Golubtsov
Ralf Mardorf
silentnoodle
Xyne

[aur-general] Clarification for Deletion request #30701

tags

participants (16)