You are not logged in.

#1 2019-02-14 05:19:30

jamespharvey20
Member
Registered: 2015-06-09
Posts: 129

AUR PKGBUILD policy on groups

When refreshing "gcc-git" and "binutils-git" a while ago, re-starting with core's PKGBUILD's, and only making necessary changes, I accidentally left in the "groups".  ("base" and "base-devel".)  Because I use a custom repo, and have setup devtools to use it, this led to devtools installing them instead of the official packages.

This definitely shouldn't be the case, so I've removed the "groups" entries.  (Waiting for new "gcc-git" build to complete, before I push it.)  I don't want my devtools using the -git versions, and it could be bad if any TU's used these packages and a custom repo, and pushed packages built using them to the official repos.

This led me to wonder if https://wiki.archlinux.org/index.php/Ar … submission should give a rule of not using "group" in an AUR PKGBUILD, like how there's a rule of not using "replaces" in one, unless it's an AUR package that has been renamed.

Before adding such a rule, I wanted to ask if anyone could think of a reason not to make such a rule, or if it needs to be worded more restrictively than "never".  Like, perhaps it should say you can't use a "group" of the same name that is used in the official repositories, but new group names (perhaps starting "aur-") are allowed.


Being a minimalist, I usually install packages by names instead of groups.  (Other than "base" and "base-devel".)  I don't know if there's a real concept of groups in the AUR.  I was thinking of looking at what other AUR packages use groups, but am not sure how to do that.  I'm not sure if there's a way to clone the entire AUR (since v4).

As I was expecting, since the AUR doesn't use branches like the official repos, these commands don't work:

$ git clone https://aur.archlinux.org
Cloning into 'aur.git'...
warning: You appear to have cloned an empty repository
$ git clone "ssh+git://aur@aur.archlinux.org/" aur.git
Cloning into 'aur.git'...
git-upload-pack: invalid repository name: 
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

Offline

#2 2019-02-14 07:17:57

Scimmia
Fellow
Registered: 2012-09-01
Posts: 11,466

Re: AUR PKGBUILD policy on groups

Groups are fine in AUR packages. If you use a custom repo to override official repo packages, I'm not sure why you wouldn't expect this.

Offline

#3 2019-02-14 08:45:27

jamespharvey20
Member
Registered: 2015-06-09
Posts: 129

Re: AUR PKGBUILD policy on groups

Scimmia wrote:

Groups are fine in AUR packages. If you use a custom repo to override official repo packages, I'm not sure why you wouldn't expect this.

Because of its parallels to problems that would happen if AUR PKGBUILDS didn't have a ban against "replaces" with official repo packages.  There's 2 problems I can think of for "replaces".

1. When using "pacman" to upgrade the "replaces" package or the entire system, it will automatically switch from the official repo package to the AUR one.

2. Similar to #1, when running "pacman" or "pacstrap" (like through devtools) installing "base" or "base-devel", with a custom repo with an AUR package having one of these groups, it automatically selects the AUR package.  Assuming the AUR package provides/conflicts and gives a newer pkgver.  (Without prompt, of course, in devtools' case.)

Although the AUR wiki only mentions #1 for reason of the "replaces" ban, #2 seemed similar enough to me to need an AUR ban on at least "base" or "base-devel" groups.

I see it's documented (circa. Dec 2015) that TU's must compile official packages using "extra-x86_64-build", but it could be very problematic if a TU instead compiled using a "custom-x86_64-build" they had setup to use a custom repo, and pushed a package compiled using or against developmental versions of base/base-devel packages that they had installed in it.

Maybe I was thinking overly cautiously.

Part of the reason I love using devtools is that it isolates any system changes I've made, like a gcc-git version.  I don't want it using gcc-git in devtools.  If this isn't a ban that should be in place, and if it's desired that a custom repo should be able to override official repo packages, then I can setup a second local repo that contains official package replacements, and that custom devtools doesn't use.

Offline

#4 2019-02-14 12:59:08

Trilby
Inspector Parrot
Registered: 2011-11-29
Posts: 29,449
Website

Re: AUR PKGBUILD policy on groups

jamespharvey20 wrote:

1. When using "pacman" to upgrade the "replaces" package or the entire system, it will automatically switch from the official repo package to the AUR one.

So this is an argument against 'replaces' not 'groups'.  But even at that, it's a bad one.  Pacman could never install an AUR package in this way.  Perhaps "pacman" can, but I'm not sure what you are referring to with those quotes.

jamespharvey20 wrote:

2. Similar to #1, when running "pacman" or "pacstrap" (like through devtools) installing "base" or "base-devel", with a custom repo with an AUR package having one of these groups, it automatically selects the AUR package.  Assuming the AUR package provides/conflicts and gives a newer pkgver.

This would be a problem with or without the 'group' variable set if (and only if) you put your custom repo higher in your pacman.conf than the main repos.  If you don't want custom repo packages to replace main repo packages, then put it at the bottom of your pacman.conf - this has nothing to do with 'groups' settings.


"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" -  Richard Stallman

Offline

#5 2019-02-14 15:46:36

Scimmia
Fellow
Registered: 2012-09-01
Posts: 11,466

Re: AUR PKGBUILD policy on groups

There is no "replaces ban". There's an advisory because people tend to use 'replaces' incorrectly, the restriction mentioned is for PKGBUILDs in general, not specific to the AUR.

Last edited by Scimmia (2019-02-14 15:47:26)

Offline

#6 2019-02-14 20:48:21

eschwartz
Fellow
Registered: 2014-08-08
Posts: 4,097

Re: AUR PKGBUILD policy on groups

jamespharvey20 wrote:

When refreshing "gcc-git" and "binutils-git" a while ago, re-starting with core's PKGBUILD's, and only making necessary changes, I accidentally left in the "groups".  ("base" and "base-devel".)  Because I use a custom repo, and have setup devtools to use it, this led to devtools installing them instead of the official packages.

This definitely shouldn't be the case, so I've removed the "groups" entries.  (Waiting for new "gcc-git" build to complete, before I push it.)  I don't want my devtools using the -git versions, and it could be bad if any TU's used these packages and a custom repo, and pushed packages built using them to the official repos.

This could be argued as logical, in that they do not semantically belong in base or base-devel. gcc and binutils *git* versions are not explicitly required in preference over the non-git versions as part of the fundamental concept of using makepkg (base-devel) or pacstrapping a new system (base)

This led me to wonder if https://wiki.archlinux.org/index.php/Ar … submission should give a rule of not using "group" in an AUR PKGBUILD, like how there's a rule of not using "replaces" in one, unless it's an AUR package that has been renamed.

As Scimmia said, this is simply false information. replaces is not and has never been banned from use in the AUR, regardless of which package has been replaced. It is simply that the word "replaces" has an actual meaning, and most people who use it don't seem to physically comprehend that it is invalid logic to mark a package as a replaces for reasons that are completely illegitimate and have nothing to do with what man PKGBUILD(5) says the word "replaces" means.

Before adding such a rule, I wanted to ask if anyone could think of a reason not to make such a rule, or if it needs to be worded more restrictively than "never".  Like, perhaps it should say you can't use a "group" of the same name that is used in the official repositories, but new group names (perhaps starting "aur-") are allowed.

Do not "add such a rule". You are not the arbiter of the Rules of Submission, all such changes must go through consensus-based talk page discussion if you expect them to be controversial, and I'm announcing right now that I am in controversy over it. :)

Moreover, I enthusiastically mark my AUR packages as members of groups such as "firefox-addons" or "vim-plugins" (both groups exist in the official repos) and believe I am justified in doing so, as it provides useful utility to the user.

jamespharvey20 wrote:

I see it's documented (circa. Dec 2015) that TU's must compile official packages using "extra-x86_64-build", but it could be very problematic if a TU instead compiled using a "custom-x86_64-build" they had setup to use a custom repo, and pushed a package compiled using or against developmental versions of base/base-devel packages that they had installed in it.

Maybe I was thinking overly cautiously.

Part of the reason I love using devtools is that it isolates any system changes I've made, like a gcc-git version.  I don't want it using gcc-git in devtools.  If this isn't a ban that should be in place, and if it's desired that a custom repo should be able to override official repo packages, then I can setup a second local repo that contains official package replacements, and that custom devtools doesn't use.

There are a few reasons why none of this matters:

1) replaces does not permit a lower-priority repository to replace a package owned by a higher-priority repository.
2) packages with the same name in two different repos do not allow you to install the lower-priority one using pacman -S pkgname, you must use pacman -S lowerrepo/pkgname
3) groups are not automatically installed except in the case of devtools, in which case base-devel is automatically installed, but you don't need to add anything to this group and it makes no sense for any other group to be installed in a chroot

and specifically in the case of a TU,

4) The official repos have checks in place to ensure that any package which was compiled in a chroot that also contained a package not available in the official repos, is blacklisted and cannot be uploaded. This is an annoying pain, as it is supposed to be -- because if a TU tries to innocently upload some package and gets an error back:

$ /community/db-update
==> ERROR: could not find existing or staged package for dependency foopkg-1.0-1-any
==> ERROR: Package /home/eschwartz/staging/community/updatedpkg-2.0-1-any.pkg.tar.xz is not reproducible.
==> ERROR:  Ensure that all dependencies are available in the repositories or are added in the same db-update.

then rebuilding that package is no more annoying to the TU than it is annoying to the people who would otherwise be trying to exercise https://reproducible-builds.org/ by reproducing that package and discovering that it was some shady binary with unverifiable inputs producing unverifiable output.


Managing AUR repos The Right Way -- aurpublish (now a standalone tool)

Offline

#7 2019-02-15 08:40:12

jamespharvey20
Member
Registered: 2015-06-09
Posts: 129

Re: AUR PKGBUILD policy on groups

First, I understand there's no support for my original proposal, so I'm somewhere between considering it withdrawn and dead, or massively shrinking the proposed suggestion to have something to do with having AUR packages have groups of "base" or "base-devel", whether that be banned or less strongly worded as merely a suggestion against doing it.

Offline

#8 2019-02-15 08:40:42

jamespharvey20
Member
Registered: 2015-06-09
Posts: 129

Re: AUR PKGBUILD policy on groups

Trilby wrote:
jamespharvey20 wrote:

1. When using "pacman" to upgrade the "replaces" package or the entire system, it will automatically switch from the official repo package to the AUR one.

So this is an argument against 'replaces' not 'groups'.

Yes, these 2 items were arguments against "replaces" in most circumstances it's historically been misused.  The last sentence in this quote was intended to mean that #1 didn't apply the groups, but #2 applied similarly to "groups".  I could have worded it more clearly.

jamespharvey20 wrote:

... There's 2 problems I can think of for "replaces"...
1. ...
2. ...
Although the AUR wiki only mentions #1 for reason of the "replaces" ban, #2 seemed similar enough to me to need an AUR ban on at least "base" or "base-devel" groups.

Trilby wrote:

But even at that, it's a bad one.  Pacman could never install an AUR package in this way.

You're absolutely right.  I should have realized that "pacman -Syu" never installed my "-git" packages on systems not explicitly asking for them.  But, that reason is what's given on the Wiki for AUR:

Arch Wiki - AUR#Rules of submission:

Rules of submission
When submitting a package to the AUR, observe the following rules:
...
* Do not use "replaces" in an AUR PKGBUILD unless the package is to be renamed, for example when Ethereal became Wireshark.  If the package is an alternate version of an already existing package, use "conflicts" (and "provides" if that package is required by others). The main difference is: after syncing (-Sy) pacman immediately wants to replace an installed, 'offending' package upon encountering a package with the matching "replaces" anywhere in its repositories; "conflicts", on the other hand, is only evaluated when actually installing the package, which is usually the desired behavior because it is less invasive.

It was added to this page on Jan 7 2017 by Wget, as a merge from "Arch_packaging_standards#AUR_packages".

On that page, the language was originally written by Byte on July 22, 2006.

So, the current AUR Wiki page has that from 13 years ago, presumably when "pacman" had different behavior.

Trilby wrote:

Perhaps "pacman" can, but I'm not sure what you are referring to with those quotes.

I usually quote things that I'd otherwise give an inline code tag to, since FluxxBB currently doesn't support that, like you're doing with 'replaces' and 'groups'.  :-)  (If/when FluxxBB v1.6 comes out, there will finally be be a new "[c]" tag that was added to their repo 3 years ago.)

Trilby wrote:
jamespharvey20 wrote:

2. Similar to #1, when running "pacman" or "pacstrap" (like through devtools) installing "base" or "base-devel", with a custom repo with an AUR package having one of these groups, it automatically selects the AUR package.  Assuming the AUR package provides/conflicts and gives a newer pkgver.

This would be a problem with or without the 'group' variable set if (and only if) you put your custom repo higher in your pacman.conf than the main repos.  If you don't want custom repo packages to replace main repo packages, then put it at the bottom of your pacman.conf - this has nothing to do with 'groups' settings.

If that's how it's intended to operate through devtools, there must be a bug.  My custom repo has always been at the bottom of any of my pacman conf files, "/etc/pacman.conf" and "/usr/share/devtools/pacman-custom.conf".  As shown below, with a "pacman-custom.conf" unmodified other than having "archLocalRepo" as the bottom repo, a "custom-x86_64-build" symlink to "archbuild", and the old version of "binutils-git" which had "groups=(base-devel)", 'provides=("binutils=${pkgver}")', and "conflicts=(binutils-multilib binutils)", then "custom-x86_64-build" installs the "-git" version instead.  With "groups" removed, and it makes no mention of "binutils-git".

I reproduced this on a clean install, to make sure I didn't have something else causing it.

$ cat /usr/share/devtools/pacman-custom.conf
[archLocalRepo]
...
SigLevel = Optional TrustAll
Server = file:///persistent/archLocalRepo
$ sudo rm -rf /var/lib/archbuild/custom-x86_64/ && custom-x86_64-build
==> Creating chroot for [custom] (x86_64)...
Create subvolume '/var/lib/archbuild/custom-x86_64/root'
==> Creating install root at /var/lib/archbuild/custom-x86_64/root
==> Installing packages to /var/lib/archbuild/custom-x86_64/root
:: Synchronizing package databases...
 core                                                                   133.4 KiB   413K/s 00:00 [########################################################] 100%
 extra                                                                 1709.3 KiB   772K/s 00:02 [########################################################] 100%
 community                                                                4.9 MiB  1149K/s 00:04 [########################################################] 100%
 archLocalRepo                                                           17.8 KiB  0.00B/s 00:00 [########################################################] 100%
:: There are 27 members in group base-devel:
:: Repository core
   1) autoconf  2) automake  3) binutils  4) bison  5) fakeroot  6) file  7) findutils  8) flex  9) gawk  10) gcc  11) gettext  12) grep  13) groff  14) gzip
   15) libtool  16) m4  17) make  18) pacman  19) patch  20) pkgconf  21) sed  22) sudo  23) systemd  24) texinfo  25) util-linux  26) which
:: Repository archLocalRepo
   27) binutils-git

Enter a selection (default=all):
resolving dependencies...
looking for conflicting packages...
warning: removing 'binutils' from target list because it conflicts with 'binutils-git'
...
               binutils-git-2.31.r95795.4de5434b69-1

Offline

#9 2019-02-15 08:41:14

jamespharvey20
Member
Registered: 2015-06-09
Posts: 129

Re: AUR PKGBUILD policy on groups

Scimmia wrote:

There is no "replaces ban". There's an advisory because people tend to use 'replaces' incorrectly, the restriction mentioned is for PKGBUILDs in general, not specific to the AUR.

See the quote from the Arch Wiki for the AUR, in my response to Trilby.  As it's worded, "Rules... observe the following rules... Do not use replaces in an AUR PKGBUILD unless the package is to be renamed" is a ban, and gives no language for wiggle room to be an advisory.  Maybe it isn't meant to be an actual ban, and it's just worded as strongly as it is to get people who don't really have a valid usage of it to not misuse it.  As mentioned, this was written in 2006, so must be out of date and needs re-wording.

Offline

#10 2019-02-15 08:41:44

jamespharvey20
Member
Registered: 2015-06-09
Posts: 129

Re: AUR PKGBUILD policy on groups

eschwartz wrote:
jamespharvey20 wrote:

When refreshing "gcc-git" and "binutils-git" a while ago, re-starting with core's PKGBUILD's, and only making necessary changes, I accidentally left in the "groups".  ("base" and "base-devel".)  Because I use a custom repo, and have setup devtools to use it, this led to devtools installing them instead of the official packages.

This definitely shouldn't be the case, so I've removed the "groups" entries.  (Waiting for new "gcc-git" build to complete, before I push it.)  I don't want my devtools using the -git versions, and it could be bad if any TU's used these packages and a custom repo, and pushed packages built using them to the official repos.

This could be argued as logical, in that they do not semantically belong in base or base-devel. gcc and binutils *git* versions are not explicitly required in preference over the non-git versions as part of the fundamental concept of using makepkg (base-devel) or pacstrapping a new system (base)

OK, I'll keep my "groups" entries removed in these packages, but as mentioned, I withdraw my proposal for a new rule, unless consensus formed behind mentioning something specifically about AUR PKGBUILD's and groups "base" and "base-devel".

I didn't check them all, but I went through 17 base packages alphabetically up until "gzip", and checked their "-git" versions.  AUR PKGBUILDS for "cryptsetup-git", "device-mapper-git", "e2fsprogs-git", "file-git", and "glibc-git" have groups of "base" or "base-devel".  Out of the 17 I checked, 10 had them, and 7 didn't.

eschwartz wrote:
jamespharvey20 wrote:

This led me to wonder if https://wiki.archlinux.org/index.php/Ar … submission should give a rule of not using "group" in an AUR PKGBUILD, like how there's a rule of not using "replaces" in one, unless it's an AUR package that has been renamed.

As Scimmia said, this is simply false information. replaces is not and has never been banned from use in the AUR, regardless of which package has been replaced. It is simply that the word "replaces" has an actual meaning, and most people who use it don't seem to physically comprehend that it is invalid logic to mark a package as a replaces for reasons that are completely illegitimate and have nothing to do with what man PKGBUILD(5) says the word "replaces" means.

See the quote from the AUR Wiki that I gave above to Scimmia.  As worded, I don't know how else to take it, except as a ban against using it in the situation of "alternate version" packages, only allowing it if a package has been renamed.  As mentioned, this was written in 2006, so must be out of date and needs re-wording.

eschwartz wrote:
jamespharvey20 wrote:

Before adding such a rule, I wanted to ask if anyone could think of a reason not to make such a rule, or if it needs to be worded more restrictively than "never".  Like, perhaps it should say you can't use a "group" of the same name that is used in the official repositories, but new group names (perhaps starting "aur-") are allowed.

Do not "add such a rule". You are not the arbiter of the Rules of Submission, all such changes must go through consensus-based talk page discussion if you expect them to be controversial, and I'm announcing right now that I am in controversy over it. smile

I won't, and I recognize that.  smile  I only would have if the responses here were all in support of it without controversy.  I wasn't expecting controversy, but knew there was a chance of it, which is why I started this discussion.  I am a bit confused though why if you're saying "This could be argued as logical" that there shouldn't be some type of addition to the AUR wiki page covering similar situations that would be logical, perhaps not as a "do not" rule, but a suggestion, and perhaps limited to "base" and "base-devel".

eschwartz wrote:
jamespharvey20 wrote:

I see it's documented (circa. Dec 2015) that TU's must compile official packages using "extra-x86_64-build", but it could be very problematic if a TU instead compiled using a "custom-x86_64-build" they had setup to use a custom repo, and pushed a package compiled using or against developmental versions of base/base-devel packages that they had installed in it.

Maybe I was thinking overly cautiously.

Part of the reason I love using devtools is that it isolates any system changes I've made, like a gcc-git version.  I don't want it using gcc-git in devtools.  If this isn't a ban that should be in place, and if it's desired that a custom repo should be able to override official repo packages, then I can setup a second local repo that contains official package replacements, and that custom devtools doesn't use.

There are a few reasons why none of this matters:

1) replaces does not permit a lower-priority repository to replace a package owned by a higher-priority repository.

Agreed "replaces" does not.  But, as shown in reply to Trilby, that's not how devtools with "groups"/"provides"/"conflicts" currently acts.  With "archLocalRepo" as the bottom repo, and "binutils-git" with "groups=(base-devel)", "provides=("binutils=${pkgver}")", and "conflicts=(binutils-multilib binutils)", "custom-x86_64-build" installs the "-git" version instead.  Removing "groups", and it makes no mention of "binutils-git".

eschwartz wrote:

2) packages with the same name in two different repos do not allow you to install the lower-priority one using pacman -S pkgname, you must use pacman -S lowerrepo/pkgname

Agreed.

eschwartz wrote:

3) groups are not automatically installed except in the case of devtools, in which case base-devel is automatically installed, but you don't need to add anything to this group and it makes no sense for any other group to be installed in a chroot

Agreed that I don't need to add anything to that group, and that it makes no sense for anything other than base and base-devel to be installed in a chroot.  Because I didn't need to add anything to that group, that's why I was thinking there could be something added to the AUR Wiki covering this situation.  Since using some official repo groups has been shown to be desired, maybe a ban (or suggestion if ban is deemed too strict) specific to base and base-devel.

Roughly having half of the base packages that have AUR -git packages still containing base, and roughly have removing it, seems odd, and like there should be consistency there, but if it's fixed so it doesn't pull anything out of a lower repo, then it probably wouldn't matter.

eschwartz wrote:

and specifically in the case of a TU,

4) The official repos have checks in place to ensure that any package which was compiled in a chroot that also contained a package not available in the official repos, is blacklisted and cannot be uploaded. This is an annoying pain, as it is supposed to be -- because if a TU tries to innocently upload some package and gets an error back:

$ /community/db-update
==> ERROR: could not find existing or staged package for dependency foopkg-1.0-1-any
==> ERROR: Package /home/eschwartz/staging/community/updatedpkg-2.0-1-any.pkg.tar.xz is not reproducible.
==> ERROR:  Ensure that all dependencies are available in the repositories or are added in the same db-update.

then rebuilding that package is no more annoying to the TU than it is annoying to the people who would otherwise be trying to exercise https://reproducible-builds.org/ by reproducing that package and discovering that it was some shady binary with unverifiable inputs producing unverifiable output.

Awesome, didn't know that existed.

Offline

#11 2019-02-15 14:25:14

Scimmia
Fellow
Registered: 2012-09-01
Posts: 11,466

Re: AUR PKGBUILD policy on groups

jamespharvey20 wrote:
Scimmia wrote:

There is no "replaces ban". There's an advisory because people tend to use 'replaces' incorrectly, the restriction mentioned is for PKGBUILDs in general, not specific to the AUR.

See the quote from the Arch Wiki for the AUR, in my response to Trilby.  As it's worded, "Rules... observe the following rules... Do not use replaces in an AUR PKGBUILD unless the package is to be renamed" is a ban, and gives no language for wiggle room to be an advisory.  Maybe it isn't meant to be an actual ban, and it's just worded as strongly as it is to get people who don't really have a valid usage of it to not misuse it.  As mentioned, this was written in 2006, so must be out of date and needs re-wording.

jamespharvey20 wrote:
eschwartz wrote:

As Scimmia said, this is simply false information. replaces is not and has never been banned from use in the AUR, regardless of which package has been replaced. It is simply that the word "replaces" has an actual meaning, and most people who use it don't seem to physically comprehend that it is invalid logic to mark a package as a replaces for reasons that are completely illegitimate and have nothing to do with what man PKGBUILD(5) says the word "replaces" means.

See the quote from the AUR Wiki that I gave above to Scimmia.  As worded, I don't know how else to take it, except as a ban against using it in the situation of "alternate version" packages, only allowing it if a package has been renamed.  As mentioned, this was written in 2006, so must be out of date and needs re-wording.

All you're doing is proving the point; you have no idea what "replaces" is, and that is why the advisory is there.

Offline

#12 2019-02-15 18:10:05

eschwartz
Fellow
Registered: 2014-08-08
Posts: 4,097

Re: AUR PKGBUILD policy on groups

jamespharvey20 wrote:

OK, I'll keep my "groups" entries removed in these packages, but as mentioned, I withdraw my proposal for a new rule, unless consensus formed behind mentioning something specifically about AUR PKGBUILD's and groups "base" and "base-devel".

I didn't check them all, but I went through 17 base packages alphabetically up until "gzip", and checked their "-git" versions.  AUR PKGBUILDS for "cryptsetup-git", "device-mapper-git", "e2fsprogs-git", "file-git", and "glibc-git" have groups of "base" or "base-devel".  Out of the 17 I checked, 10 had them, and 7 didn't.

glibc-git at least only lists base, which is not installed automatically by a script so I'm fine leaving it that way (I'm the maintainer).

jamespharvey20 wrote:

See the quote from the AUR Wiki that I gave above to Scimmia.  As worded, I don't know how else to take it, except as a ban against using it in the situation of "alternate version" packages, only allowing it if a package has been renamed.  As mentioned, this was written in 2006, so must be out of date and needs re-wording.

It is not out of date and does not need rewording. Once again, the semantic intent of the keyword "replaces" is for a package that was renamed. At least, that is what 99% of legitimate use cases of replaces are for.

It makes no difference whether the package is in the AUR or the official repos -- it is the exact same issue, with the exact same solution: don't use replaces unless the other package has been removed, no longer exists, and users are expected to find the old software bundle under a different name.

jamespharvey20 wrote:

I am a bit confused though why if you're saying "This could be argued as logical" that there shouldn't be some type of addition to the AUR wiki page covering similar situations that would be logical, perhaps not as a "do not" rule, but a suggestion, and perhaps limited to "base" and "base-devel".

It could also be disputed. For example, I recognize the practicality of not using base-devel, but I do not see why that should apply to base (which I wish to use in order to more easily pacstrap a system using glibc-git, by recommending it for the interactive selection dialog as part of base).

jamespharvey20 wrote:

Agreed "replaces" does not.  But, as shown in reply to Trilby, that's not how devtools with "groups"/"provides"/"conflicts" currently acts.  With "archLocalRepo" as the bottom repo, and "binutils-git" with "groups=(base-devel)", "provides=("binutils=${pkgver}")", and "conflicts=(binutils-multilib binutils)", "custom-x86_64-build" installs the "-git" version instead.  Removing "groups", and it makes no mention of "binutils-git".

This is because the base-devel group includes both binutils and binutils-git, and gives you an option to interactively select both, either, or none, along with all other members of the group.

If I do the same thing, pacstrapping a system with glibc-git in base, I get the following status message:

:: There are 51 members in group base:
:: Repository eschwartz
   1) glibc-git
:: Repository testing
   2) netctl  3) systemd-sysvcompat
:: Repository core
   4) bash  5) bzip2  6) coreutils  7) cryptsetup  8) device-mapper  9) dhcpcd  10) diffutils  11) e2fsprogs  12) file  13) filesystem  14) findutils
   15) gawk  16) gcc-libs  17) gettext  18) glibc  19) grep  20) gzip  21) inetutils  22) iproute2  23) iputils  24) jfsutils  25) less  26) licenses
   27) linux  28) linux-firmware  29) logrotate  30) lvm2  31) man-db  32) man-pages  33) mdadm  34) nano  35) pacman  36) pciutils  37) perl
   38) procps-ng  39) psmisc  40) reiserfsprogs  41) s-nail  42) sed  43) shadow  44) sysfsutils  45) tar  46) texinfo  47) usbutils  48) util-linux
   49) vi  50) which  51) xfsprogs

Enter a selection (default=all): 
resolving dependencies...
:: There are 2 providers available for libsystemd:
:: Repository testing
   1) systemd-libs
:: Repository core
   2) systemd-libs

Enter a number (default=1): 
:: There are 3 providers available for resolvconf:
:: Repository testing
   1) systemd-resolvconf
:: Repository core
   2) openresolv  3) systemd-resolvconf

Enter a number (default=1): 
looking for conflicting packages...
warning: removing 'glibc' from target list because it conflicts with 'glibc-git'

That last line is very clear on what is happening. It's quite specific to the use of groups, and it only happens when pacstrap is used to select packages using auto-confirmation.

jamespharvey20 wrote:

Agreed that I don't need to add anything to that group, and that it makes no sense for anything other than base and base-devel to be installed in a chroot.  Because I didn't need to add anything to that group, that's why I was thinking there could be something added to the AUR Wiki covering this situation.  Since using some official repo groups has been shown to be desired, maybe a ban (or suggestion if ban is deemed too strict) specific to base and base-devel.

Roughly having half of the base packages that have AUR -git packages still containing base, and roughly have removing it, seems odd, and like there should be consistency there, but if it's fixed so it doesn't pull anything out of a lower repo, then it probably wouldn't matter.

Lower repos only affect two packages which shadow each other using the same pkgname.

jamespharvey20 wrote:
eschwartz wrote:

and specifically in the case of a TU,

4) The official repos have checks in place to ensure that any package which was compiled in a chroot that also contained a package not available in the official repos, is blacklisted and cannot be uploaded. This is an annoying pain, as it is supposed to be -- because if a TU tries to innocently upload some package and gets an error back:

$ /community/db-update
==> ERROR: could not find existing or staged package for dependency foopkg-1.0-1-any
==> ERROR: Package /home/eschwartz/staging/community/updatedpkg-2.0-1-any.pkg.tar.xz is not reproducible.
==> ERROR:  Ensure that all dependencies are available in the repositories or are added in the same db-update.

then rebuilding that package is no more annoying to the TU than it is annoying to the people who would otherwise be trying to exercise https://reproducible-builds.org/ by reproducing that package and discovering that it was some shady binary with unverifiable inputs producing unverifiable output.

Awesome, didn't know that existed.

Actually it is a relatively recent development, as I was one of the people getting annoyed by it. smile


Managing AUR repos The Right Way -- aurpublish (now a standalone tool)

Offline

Board footer

Powered by FluxBB