A first release candidate of the AUR 3.0.0 has been released! You can give it a try at [1]. Note that due to internal changes, the setup at aur-dev.archlinux.org uses a different database than aur.archlinux.org. You should be able login using your regular AUR account, though.
The most important changes are:
* Full split package support. * Support for {make,check,opt}depends, conflicts, provides, ... * Full support for the new fields in the RPC interface. * Metadata support. Use mkaurball instead of `makepkg --source` to generate source tarballs for the AUR`. You can get it from [2] -- it will eventually be moved to [community].
Note that in order to obtain the new fields, you need to request the new version of the RPC API explicitly, like this:
https://aur-dev.archlinux.org/rpc.php?type=info&arg=pass&v=2
Otherwise, the replies default to the old format for compatibility reasons.
Please report any bugs to the AUR bug tracker [3].
[1] https://aur-dev.archlinux.org/ [2] https://aur.archlinux.org/packages/pkgbuild-introspection-git/ [3] https://bugs.archlinux.org/index.php?project=2
On 2014-04-30 17:20, Lukas Fleischer wrote:
A first release candidate of the AUR 3.0.0 has been released! You can give it a try at [1]. Note that due to internal changes, the setup at aur-dev.archlinux.org uses a different database than aur.archlinux.org. You should be able login using your regular AUR account, though.
The most important changes are:
- Full split package support.
- Support for {make,check,opt}depends, conflicts, provides, ...
- Full support for the new fields in the RPC interface.
- Metadata support. Use mkaurball instead of `makepkg --source` to generate source tarballs for the AUR`. You can get it from [2] -- it will eventually be moved to [community].
Note that in order to obtain the new fields, you need to request the new version of the RPC API explicitly, like this:
https://aur-dev.archlinux.org/rpc.php?type=info&arg=pass&v=2Otherwise, the replies default to the old format for compatibility reasons.
Please report any bugs to the AUR bug tracker [3].
[1] https://aur-dev.archlinux.org/ [2] https://aur.archlinux.org/packages/pkgbuild-introspection-git/ [3] https://bugs.archlinux.org/index.php?project=2
It appears that pkgbase is now the important part of a PKGBUILD, that's what people would be requesting deletion or merging on? Makes merges a bit tough, since you can't upload a PKGBUILD with a different pkgbase but an overlapping pkgname.
On Wed, Apr 30, 2014 at 06:57:33PM -0500, Doug Newgard wrote:
On 2014-04-30 17:20, Lukas Fleischer wrote:
A first release candidate of the AUR 3.0.0 has been released! You can give it a try at [1]. Note that due to internal changes, the setup at aur-dev.archlinux.org uses a different database than aur.archlinux.org. You should be able login using your regular AUR account, though.
The most important changes are:
- Full split package support.
- Support for {make,check,opt}depends, conflicts, provides, ...
- Full support for the new fields in the RPC interface.
- Metadata support. Use mkaurball instead of `makepkg --source` to
generate source tarballs for the AUR`. You can get it from [2] -- it will eventually be moved to [community].
Note that in order to obtain the new fields, you need to request the new version of the RPC API explicitly, like this:
https://aur-dev.archlinux.org/rpc.php?type=info&arg=pass&v=2
Otherwise, the replies default to the old format for compatibility reasons.
Please report any bugs to the AUR bug tracker [3].
[1] https://aur-dev.archlinux.org/ [2] https://aur.archlinux.org/packages/pkgbuild-introspection-git/ [3] https://bugs.archlinux.org/index.php?project=2
It appears that pkgbase is now the important part of a PKGBUILD,
But note that it doesn't need to be included. Same as makepkg, it defaults to pkgname[0] if it isn't defined.
that's what people would be requesting deletion or merging on? Makes merges a bit tough, since you can't upload a PKGBUILD with a different pkgbase but an overlapping pkgname.
You'd be referring to the package by its pkgbase, since that's the unifying factor. If 'foo' is split into 'python-foo' and 'python2-foo', you wouldn't ask to merge/delete 'python-foo' or 'python2-foo'. This doesn't make sense -- you'd just upload a new source tarball with the modification.
I don't understand your concern over overlapping pkgnames. If you want to take ownership of existing packages, you should be asking for the package to be disowned, not merged, same as today.
Hi,
On Wed, Apr 30, 2014 at 8:37 PM, Dave Reisner d@falconindy.com wrote:
On Wed, Apr 30, 2014 at 06:57:33PM -0500, Doug Newgard wrote:
On 2014-04-30 17:20, Lukas Fleischer wrote:
A first release candidate of the AUR 3.0.0 has been released! You can give it a try at [1]. Note that due to internal changes, the setup at aur-dev.archlinux.org uses a different database than aur.archlinux.org. You should be able login using your regular AUR account, though.
The most important changes are:
- Full split package support.
- Support for {make,check,opt}depends, conflicts, provides, ...
- Full support for the new fields in the RPC interface.
- Metadata support. Use mkaurball instead of `makepkg --source` to
generate source tarballs for the AUR`. You can get it from [2] -- it will eventually be moved to [community].
Note that in order to obtain the new fields, you need to request the new version of the RPC API explicitly, like this:
https://aur-dev.archlinux.org/rpc.php?type=info&arg=pass&v=2
Otherwise, the replies default to the old format for compatibility reasons.
Please report any bugs to the AUR bug tracker [3].
[1] https://aur-dev.archlinux.org/ [2] https://aur.archlinux.org/packages/pkgbuild-introspection-git/ [3] https://bugs.archlinux.org/index.php?project=2
It appears that pkgbase is now the important part of a PKGBUILD,
But note that it doesn't need to be included. Same as makepkg, it defaults to pkgname[0] if it isn't defined.
that's what people would be requesting deletion or merging on? Makes merges a bit tough, since you can't upload a PKGBUILD with a different pkgbase but an overlapping pkgname.
You'd be referring to the package by its pkgbase, since that's the unifying factor. If 'foo' is split into 'python-foo' and 'python2-foo', you wouldn't ask to merge/delete 'python-foo' or 'python2-foo'. This doesn't make sense -- you'd just upload a new source tarball with the modification.
I don't understand your concern over overlapping pkgnames. If you want to take ownership of existing packages, you should be asking for the package to be disowned, not merged, same as today.
I'm not sure if this is the original concern but one of my concern that might be related is that for example there are two packages python-foo and python2-foo which provide the python3 and python2 versions respectively. What should I do if I want to merge the two packages into a split package that provide both. Asking for merge and update the package later? AUR won't let me to upload a new version of python-foo that provide python2-foo otherwise.
Cheers.
Yichao Yu
On Wed, Apr 30, 2014 at 08:45:16PM -0400, Yichao Yu wrote:
Hi,
On Wed, Apr 30, 2014 at 8:37 PM, Dave Reisner d@falconindy.com wrote:
On Wed, Apr 30, 2014 at 06:57:33PM -0500, Doug Newgard wrote:
On 2014-04-30 17:20, Lukas Fleischer wrote:
A first release candidate of the AUR 3.0.0 has been released! You can give it a try at [1]. Note that due to internal changes, the setup at aur-dev.archlinux.org uses a different database than aur.archlinux.org. You should be able login using your regular AUR account, though.
The most important changes are:
- Full split package support.
- Support for {make,check,opt}depends, conflicts, provides, ...
- Full support for the new fields in the RPC interface.
- Metadata support. Use mkaurball instead of `makepkg --source` to
generate source tarballs for the AUR`. You can get it from [2] -- it will eventually be moved to [community].
Note that in order to obtain the new fields, you need to request the new version of the RPC API explicitly, like this:
https://aur-dev.archlinux.org/rpc.php?type=info&arg=pass&v=2
Otherwise, the replies default to the old format for compatibility reasons.
Please report any bugs to the AUR bug tracker [3].
[1] https://aur-dev.archlinux.org/ [2] https://aur.archlinux.org/packages/pkgbuild-introspection-git/ [3] https://bugs.archlinux.org/index.php?project=2
It appears that pkgbase is now the important part of a PKGBUILD,
But note that it doesn't need to be included. Same as makepkg, it defaults to pkgname[0] if it isn't defined.
that's what people would be requesting deletion or merging on? Makes merges a bit tough, since you can't upload a PKGBUILD with a different pkgbase but an overlapping pkgname.
You'd be referring to the package by its pkgbase, since that's the unifying factor. If 'foo' is split into 'python-foo' and 'python2-foo', you wouldn't ask to merge/delete 'python-foo' or 'python2-foo'. This doesn't make sense -- you'd just upload a new source tarball with the modification.
I don't understand your concern over overlapping pkgnames. If you want to take ownership of existing packages, you should be asking for the package to be disowned, not merged, same as today.
I'm not sure if this is the original concern but one of my concern that might be related is that for example there are two packages python-foo and python2-foo which provide the python3 and python2 versions respectively. What should I do if I want to merge the two packages into a split package that provide both. Asking for merge and update the package later? AUR won't let me to upload a new version of python-foo that provide python2-foo otherwise.
Then you update the package after the merge happens, rather than before (and perhaps attach your PKGBUILD to the merge request).
On 2014-04-30 19:45, Yichao Yu wrote:
Hi,
On Wed, Apr 30, 2014 at 8:37 PM, Dave Reisner d@falconindy.com wrote:
On Wed, Apr 30, 2014 at 06:57:33PM -0500, Doug Newgard wrote:
On 2014-04-30 17:20, Lukas Fleischer wrote:
A first release candidate of the AUR 3.0.0 has been released! You can give it a try at [1]. Note that due to internal changes, the setup at aur-dev.archlinux.org uses a different database than aur.archlinux.org. You should be able login using your regular AUR account, though.
The most important changes are:
- Full split package support.
- Support for {make,check,opt}depends, conflicts, provides, ...
- Full support for the new fields in the RPC interface.
- Metadata support. Use mkaurball instead of `makepkg --source` to
generate source tarballs for the AUR`. You can get it from [2] -- it will eventually be moved to [community].
Note that in order to obtain the new fields, you need to request the new version of the RPC API explicitly, like this:
https://aur-dev.archlinux.org/rpc.php?type=info&arg=pass&v=2
Otherwise, the replies default to the old format for compatibility reasons.
Please report any bugs to the AUR bug tracker [3].
[1] https://aur-dev.archlinux.org/ [2] https://aur.archlinux.org/packages/pkgbuild-introspection-git/ [3] https://bugs.archlinux.org/index.php?project=2
It appears that pkgbase is now the important part of a PKGBUILD,
But note that it doesn't need to be included. Same as makepkg, it defaults to pkgname[0] if it isn't defined.
that's what people would be requesting deletion or merging on? Makes merges a bit tough, since you can't upload a PKGBUILD with a different pkgbase but an overlapping pkgname.
You'd be referring to the package by its pkgbase, since that's the unifying factor. If 'foo' is split into 'python-foo' and 'python2-foo', you wouldn't ask to merge/delete 'python-foo' or 'python2-foo'. This doesn't make sense -- you'd just upload a new source tarball with the modification.
I don't understand your concern over overlapping pkgnames. If you want to take ownership of existing packages, you should be asking for the package to be disowned, not merged, same as today.
I'm not sure if this is the original concern but one of my concern that might be related is that for example there are two packages python-foo and python2-foo which provide the python3 and python2 versions respectively. What should I do if I want to merge the two packages into a split package that provide both. Asking for merge and update the package later? AUR won't let me to upload a new version of python-foo that provide python2-foo otherwise.
Cheers.
Yichao Yu
Yep, that was the concern exactly. Nothing insurmountable, just wanting to clarify how it works upfront.
On 1 May 2014 02:30, Doug Newgard scimmia@archlinux.info wrote:
Yep, that was the concern exactly. Nothing insurmountable, just wanting to clarify how it works upfront.
I share this concern. I've just uploaded slim-git [1] to the aur-dev:
pkgbase=slim-git pkgname=('slim-git' 'slimlock-git')
If I now wanted to change the pkgbase to something more encompassing, e.g.
pkgbase=slim-git_slimlock-git
I get the following error when I try to upload the aurball
"You are not allowed to overwrite the slim-git package."
I assume this is because my updated PKGBUILD provides slim-git (and slimlock-git), but is in essence a completely different package, because of the different pkgbase value. In this situation, I cannot upload the PKGBUILD and have the old one merged into it, due to the conflict.
As I understand it, my options are to either upload the new PKGBUILD with different/temporary pkgnames, request to have the packages merged, then undo the rename and upload the updated PKGBUILD again, with the original pkgnames.
The other option, as Dave has suggested, is to submit the updated PKGBUILD along with the merge request. Is this ideal, or would a patch that can be applied directly onto the existing PKGBUILD be a better idea? (or in this case, where a patch would be overkill, is it preferable to just ask a TU to make the changes directly to the PKGBUILD?)
Or alternatively, should pkgbase changes be disallowed completely, except where it's really necessary?
Cheers,
WorMzy
On Thu, May 01, 2014 at 01:04:07PM +0100, WorMzy Tykashi wrote:
On 1 May 2014 02:30, Doug Newgard scimmia@archlinux.info wrote:
Yep, that was the concern exactly. Nothing insurmountable, just wanting to clarify how it works upfront.
I share this concern. I've just uploaded slim-git [1] to the aur-dev:
pkgbase=slim-git pkgname=('slim-git' 'slimlock-git')
If I now wanted to change the pkgbase to something more encompassing, e.g.
pkgbase=slim-git_slimlock-git
I don't get it. pkgbase is intended to be no different from what it is in the binary repositories, e.g.:
linux -> linux linux-headers linux-docs pacman -> pacman pacman-contrib
What you're proposing here makes no sense.
I get the following error when I try to upload the aurball
"You are not allowed to overwrite the slim-git package."
I assume this is because my updated PKGBUILD provides slim-git (and slimlock-git), but is in essence a completely different package, because of the different pkgbase value. In this situation, I cannot upload the PKGBUILD and have the old one merged into it, due to the conflict.
And if you think about it, this makes sense. If pkgbase 'a' and 'b' both provide 'libfoo', then what does the URI fragment '/packages/libfoo' point to? The basic unit of upload and download has essentially changed to 'pkgbase' rather than 'pkgname', but there's still a uniqueness constraint between package names.
As I understand it, my options are to either upload the new PKGBUILD with different/temporary pkgnames, request to have the packages merged, then undo the rename and upload the updated PKGBUILD again, with the original pkgnames.
The other option, as Dave has suggested, is to submit the updated PKGBUILD along with the merge request. Is this ideal, or would a patch that can be applied directly onto the existing PKGBUILD be a better idea? (or in this case, where a patch would be overkill, is it preferable to just ask a TU to make the changes directly to the PKGBUILD?)
Allowing anyone to edit PKGBUILDs and tarballs on the webserving side as a matter of procedure should never happen. This isn't secure at all.
Or alternatively, should pkgbase changes be disallowed completely, except where it's really necessary?
Not sure what this accomplishes. If there's no pkgbase, it's just assumed to be whatever ${pkgname[0]} expands to. This is a carryover from makepkg.
Cheers,
WorMzy
On 1 May 2014 13:29, Dave Reisner d@falconindy.com wrote:
On Thu, May 01, 2014 at 01:04:07PM +0100, WorMzy Tykashi wrote:
On 1 May 2014 02:30, Doug Newgard scimmia@archlinux.info wrote:
Yep, that was the concern exactly. Nothing insurmountable, just wanting to clarify how it works upfront.
I share this concern. I've just uploaded slim-git [1] to the aur-dev:
pkgbase=slim-git pkgname=('slim-git' 'slimlock-git')
If I now wanted to change the pkgbase to something more encompassing, e.g.
pkgbase=slim-git_slimlock-git
I don't get it. pkgbase is intended to be no different from what it is in the binary repositories, e.g.:
linux -> linux linux-headers linux-docs pacman -> pacman pacman-contrib
What you're proposing here makes no sense.
Of course not, I'm an end user. ;)
This is just an example of something someone may try to do for whatever reason. It fails, and quite rightly so, you can't have two different pkgbases providing the same packages as each other. The question remains whether people should be able to alter the pkgbase of a split package. If not, that's fine. But if they are, how are they supposed to do so? Does it/should it require TU intervention?
I get the following error when I try to upload the aurball
"You are not allowed to overwrite the slim-git package."
I assume this is because my updated PKGBUILD provides slim-git (and slimlock-git), but is in essence a completely different package, because of the different pkgbase value. In this situation, I cannot upload the PKGBUILD and have the old one merged into it, due to the conflict.
And if you think about it, this makes sense. If pkgbase 'a' and 'b' both provide 'libfoo', then what does the URI fragment '/packages/libfoo' point to? The basic unit of upload and download has essentially changed to 'pkgbase' rather than 'pkgname', but there's still a uniqueness constraint between package names.
I understand this, and aren't trying to argue against it.
As I understand it, my options are to either upload the new PKGBUILD with different/temporary pkgnames, request to have the packages merged, then undo the rename and upload the updated PKGBUILD again, with the original pkgnames.
The other option, as Dave has suggested, is to submit the updated PKGBUILD along with the merge request. Is this ideal, or would a patch that can be applied directly onto the existing PKGBUILD be a better idea? (or in this case, where a patch would be overkill, is it preferable to just ask a TU to make the changes directly to the PKGBUILD?)
Allowing anyone to edit PKGBUILDs and tarballs on the webserving side as a matter of procedure should never happen. This isn't secure at all.
I must have misinterpreted what you said earlier about sending the PKGBUILD with the merger request. I assumed TUs had this capability. I agree that it's not secure.
Or alternatively, should pkgbase changes be disallowed completely, except where it's really necessary?
Not sure what this accomplishes. If there's no pkgbase, it's just assumed to be whatever ${pkgname[0]} expands to. This is a carryover from makepkg.
I know this. I'm meaning in regards to split packages specifically.
Cheers,
WorMzy
On Thu, May 01, 2014 at 02:04:42PM +0100, WorMzy Tykashi wrote:
On 1 May 2014 13:29, Dave Reisner d@falconindy.com wrote:
On Thu, May 01, 2014 at 01:04:07PM +0100, WorMzy Tykashi wrote:
On 1 May 2014 02:30, Doug Newgard scimmia@archlinux.info wrote:
Yep, that was the concern exactly. Nothing insurmountable, just wanting to clarify how it works upfront.
I share this concern. I've just uploaded slim-git [1] to the aur-dev:
pkgbase=slim-git pkgname=('slim-git' 'slimlock-git')
If I now wanted to change the pkgbase to something more encompassing, e.g.
pkgbase=slim-git_slimlock-git
I don't get it. pkgbase is intended to be no different from what it is in the binary repositories, e.g.:
linux -> linux linux-headers linux-docs pacman -> pacman pacman-contrib
What you're proposing here makes no sense.
Of course not, I'm an end user. ;)
SSDD. I fully recognize that we're extending the "attack surface" for users to do really stupid things. I think the benefits will far outweigh the negatives, and maybe there will be opportunities to automate more, reducing the reliance on human intervention for day to day operation.
This is just an example of something someone may try to do for whatever reason. It fails, and quite rightly so, you can't have two different pkgbases providing the same packages as each other. The question remains whether people should be able to alter the pkgbase of a split package. If not, that's fine. But if they are, how are they supposed to do so? Does it/should it require TU intervention?
Ask for your pkgbase to be deleted, then upload the new one. Or, play games with the package naming in the new package you upload beforehand, and have it merged. Afterwards, upload the real PKGBUILD.
I get the following error when I try to upload the aurball
"You are not allowed to overwrite the slim-git package."
I assume this is because my updated PKGBUILD provides slim-git (and slimlock-git), but is in essence a completely different package, because of the different pkgbase value. In this situation, I cannot upload the PKGBUILD and have the old one merged into it, due to the conflict.
And if you think about it, this makes sense. If pkgbase 'a' and 'b' both provide 'libfoo', then what does the URI fragment '/packages/libfoo' point to? The basic unit of upload and download has essentially changed to 'pkgbase' rather than 'pkgname', but there's still a uniqueness constraint between package names.
I understand this, and aren't trying to argue against it.
Right, this was just an extrapolation.
As I understand it, my options are to either upload the new PKGBUILD with different/temporary pkgnames, request to have the packages merged, then undo the rename and upload the updated PKGBUILD again, with the original pkgnames.
The other option, as Dave has suggested, is to submit the updated PKGBUILD along with the merge request. Is this ideal, or would a patch that can be applied directly onto the existing PKGBUILD be a better idea? (or in this case, where a patch would be overkill, is it preferable to just ask a TU to make the changes directly to the PKGBUILD?)
Allowing anyone to edit PKGBUILDs and tarballs on the webserving side as a matter of procedure should never happen. This isn't secure at all.
I must have misinterpreted what you said earlier about sending the PKGBUILD with the merger request. I assumed TUs had this capability. I agree that it's not secure.
Or alternatively, should pkgbase changes be disallowed completely, except where it's really necessary?
Not sure what this accomplishes. If there's no pkgbase, it's just assumed to be whatever ${pkgname[0]} expands to. This is a carryover from makepkg.
I know this. I'm meaning in regards to split packages specifically.
Still doesn't make sense. The same rule applies, regardless of whether or not you split the package.
d
On 30/04/14 23:20, Lukas Fleischer wrote:
A first release candidate of the AUR 3.0.0 has been released! You can give it a try at [1]. Note that due to internal changes, the setup at aur-dev.archlinux.org uses a different database than aur.archlinux.org. You should be able login using your regular AUR account, though.
The most important changes are:
- Full split package support.
- Support for {make,check,opt}depends, conflicts, provides, ...
- Full support for the new fields in the RPC interface.
- Metadata support. Use mkaurball instead of `makepkg --source` to generate source tarballs for the AUR`. You can get it from [2] -- it will eventually be moved to [community].
Note that in order to obtain the new fields, you need to request the new version of the RPC API explicitly, like this:
https://aur-dev.archlinux.org/rpc.php?type=info&arg=pass&v=2Otherwise, the replies default to the old format for compatibility reasons.
Please report any bugs to the AUR bug tracker [3].
[1] https://aur-dev.archlinux.org/ [2] https://aur.archlinux.org/packages/pkgbuild-introspection-git/ [3] https://bugs.archlinux.org/index.php?project=2
Really minor issue, but there's some overflow on timestamps in recent updates.
http://i.revthefox.co.uk/b923ce81
aur-general@lists.archlinux.org