Well, I'm addressing current blacklisting issues with the AUR [1]. I noticed that some of the packages in the official repos have AUR packages as provides, some of them (well, at least one of them, didn't search for more) were even added due to FRs [2]. Donnu if this applies to [core] and [extra] as well.
Is that regular practice? Imho, we shouldn't do that. The AUR is something to be considered separately. If we start to care about provides/conflicts with AUR packages, we'll need to add all "-devel"/"-svn"/"-git"/"-beta" packages in the AUR to the official packages conflicts and provides as well. And we'll need to start searching for alternative repos to ensure there's no conflict with our official packages.
Seriously, we should be consistent here.
[1] http://mailman.archlinux.org/pipermail/aur-general/2011-February/013811.html [2] https://bugs.archlinux.org/task/16495
Lukas Fleischer wrote:
Well, I'm addressing current blacklisting issues with the AUR [1]. I noticed that some of the packages in the official repos have AUR packages as provides, some of them (well, at least one of them, didn't search for more) were even added due to FRs [2]. Donnu if this applies to [core] and [extra] as well.
Is that regular practice? Imho, we shouldn't do that. The AUR is something to be considered separately. If we start to care about provides/conflicts with AUR packages, we'll need to add all "-devel"/"-svn"/"-git"/"-beta" packages in the AUR to the official packages conflicts and provides as well. And we'll need to start searching for alternative repos to ensure there's no conflict with our official packages.
Seriously, we should be consistent here.
Maybe that's unintentional. It could be a simple matter of forgetting to update the PKGBUILD when moving the package from AUR to [community].
The AUR is something to be considered separately.
I agree that the two should be considered separate, but officially they're not: http://mailman.archlinux.org/pipermail/aur-general/2011-February/013403.html
On Friday 25 February 2011 11:12:15 Lukas Fleischer wrote:
Well, I'm addressing current blacklisting issues with the AUR [1]. I noticed that some of the packages in the official repos have AUR packages as provides, some of them (well, at least one of them, didn't search for more) were even added due to FRs [2]. Donnu if this applies to [core] and [extra] as well.
Is that regular practice? Imho, we shouldn't do that. The AUR is something to be considered separately. If we start to care about provides/conflicts with AUR packages, we'll need to add all "-devel"/"-svn"/"-git"/"-beta" packages in the AUR to the official packages conflicts and provides as well. And we'll need to start searching for alternative repos to ensure there's no conflict with our official packages.
Seriously, we should be consistent here.
Can't remember where I read this being discussed, but I'm pretty sure that no package in [core], [extra] or [community] should reference anything in the AUR.
Pete.
On Fri, Feb 25, 2011 at 2:40 PM, Peter Lewis plewis@aur.archlinux.orgwrote:
On Friday 25 February 2011 11:12:15 Lukas Fleischer wrote:
Well, I'm addressing current blacklisting issues with the AUR [1]. I noticed that some of the packages in the official repos have AUR packages as provides, some of them (well, at least one of them, didn't search for more) were even added due to FRs [2]. Donnu if this applies to [core] and [extra] as well.
Is that regular practice? Imho, we shouldn't do that. The AUR is something to be considered separately. If we start to care about provides/conflicts with AUR packages, we'll need to add all "-devel"/"-svn"/"-git"/"-beta" packages in the AUR to the official packages conflicts and provides as well. And we'll need to start searching for alternative repos to ensure there's no conflict with our official packages.
Seriously, we should be consistent here.
Can't remember where I read this being discussed, but I'm pretty sure that no package in [core], [extra] or [community] should reference anything in the AUR.
Pete.
Right, if there is a package that is depending on an AUR package from a supported repo than it is a bug and can be reported.
-Thomas S Hatch
On Fri, 2011-02-25 at 14:42 -0700, Thomas S Hatch wrote:
On Fri, Feb 25, 2011 at 2:40 PM, Peter Lewis plewis@aur.archlinux.orgwrote:
On Friday 25 February 2011 11:12:15 Lukas Fleischer wrote:
Well, I'm addressing current blacklisting issues with the AUR [1]. I noticed that some of the packages in the official repos have AUR packages as provides, some of them (well, at least one of them, didn't search for more) were even added due to FRs [2]. Donnu if this applies to [core] and [extra] as well.
Is that regular practice? Imho, we shouldn't do that. The AUR is something to be considered separately. If we start to care about provides/conflicts with AUR packages, we'll need to add all "-devel"/"-svn"/"-git"/"-beta" packages in the AUR to the official packages conflicts and provides as well. And we'll need to start searching for alternative repos to ensure there's no conflict with our official packages.
Seriously, we should be consistent here.
Can't remember where I read this being discussed, but I'm pretty sure that no package in [core], [extra] or [community] should reference anything in the AUR.
Pete.
Right, if there is a package that is depending on an AUR package from a supported repo than it is a bug and can be reported.
-Thomas S Hatch
As I think has been previously mentioned, this probably happens with cleanups when packages are dropped? Because I don't think 'provides' gets checked, of course 'depends' and 'requires' does.
On 25 February 2011 19:12, Lukas Fleischer archlinux@cryptocrack.de wrote:
Seriously, we should be consistent here.
I agree.
* Provide/replace/conflict as necessary when promoting a package from AUR (eg. when renaming the package)
* Bump pkgrel OR force (I vote for force) for the first time (eg. so users get the repo versions and not report bugs many days later while still using the AUR package)
* Do NOT provide/conflict/replace just because of a FR for a package in AUR (unless the request is to provide for a package name that is aknowledged by many)
On 26/02/11 19:22, Ray Rashif wrote:
- Bump pkgrel OR force (I vote for force) for the first time (eg. so
users get the repo versions and not report bugs many days later while still using the AUR package)
Forces is crap (and dead in the future pacman-3.5). Bumping the pkgrel should not be an issue given the package probably is frequently updated if it is worth bring to the repos, so it will have a pkgrel of 1 again soon.
Allan
On 26 February 2011 17:40, Allan McRae allan@archlinux.org wrote:
On 26/02/11 19:22, Ray Rashif wrote:
- Bump pkgrel OR force (I vote for force) for the first time (eg. so
users get the repo versions and not report bugs many days later while still using the AUR package)
Forces is crap (and dead in the future pacman-3.5). Bumping the pkgrel should not be an issue given the package probably is frequently updated if it is worth bring to the repos, so it will have a pkgrel of 1 again soon.
Ahh right..force -> epoch.
There have been a few cases where the AUR package is pkgrel=n and the repo is pkgrel=k, and the package on the system is not updated along with the move because k=1 or k<=n. Then someone files a bug, which later turns out to be applicable only to the AUR package. So here I would start out with k=n+1, at least until we have a better way.
aur-general@lists.archlinux.org