[aur-general] pkg deletion request
Hi TUs, I made the switch to mkaurball, and I would like to have this package deleted for new renamed upload(pkgbase will become openrc-sys). https://aur.archlinux.org/pkgbase/openrc-base/ I also have aquestion. Suppose I want to move/merge a single pkgbuild to a split build, is that possible? Will the pkgbase change, so the single pkgbuld will "disappear" automatically? Or the other way round, I want to move a pkg from split build to single build? Is there any documentation for this kind of stuff? Thanks, artoo
On Fri, 30 May 2014 at 14:03:00, artux wrote:
[...] Suppose I want to move/merge a single pkgbuild to a split build, is that possible? Will the pkgbase change, so the single pkgbuld will "disappear" automatically? Or the other way round, I want to move a pkg from split build to single build? Is there any documentation for this kind of stuff?
The logic is as follows: * Package bases can be overwritten by their maintainers and by TUs. * Packages can only be overwritten if they already belong to the package base of the submitted package. That means that you cannot upload a PKGBUILD containing a package which is already part of another package base. So in order to replace several packages with a split package, you will need to: 1. Upload a (basically empty) meta package with the new package base (unless you want to use a package base that already exists, e.g. the name of the first package to merge). 2. File a request to merge every package into the new split package. 3. Upload a proper split package to replace the meta package. It is a bit unfortunate that this process makes merging a bit more complicated and results in packages being unavailable for a short transition period (see steps 1 to 3). I didn't come up with something better yet. Should we give TUs extra power and allow for uploading PKGBUILDs that automatically overwrite (and merge) packages? The downside is that this would be quite complicated to implement and we would have to ensure that no strange things can happen, e.g. partly overwriting another split package by replacing a subset of its packages. Trusted Users would also have to have a very close look at the packages before merging to ensure that no malicious takeover happens. Any suggestions are welcome.
Thanks, artoo
On Fri, May 30, 2014 at 12:17 PM, Lukas Fleischer <archlinux@cryptocrack.de> wrote:
On Fri, 30 May 2014 at 14:03:00, artux wrote:
[...] Suppose I want to move/merge a single pkgbuild to a split build, is that possible? Will the pkgbase change, so the single pkgbuld will "disappear" automatically? Or the other way round, I want to move a pkg from split build to single build? Is there any documentation for this kind of stuff?
The logic is as follows:
* Package bases can be overwritten by their maintainers and by TUs.
* Packages can only be overwritten if they already belong to the package base of the submitted package. That means that you cannot upload a PKGBUILD containing a package which is already part of another package base.
So in order to replace several packages with a split package, you will need to:
1. Upload a (basically empty) meta package with the new package base (unless you want to use a package base that already exists, e.g. the name of the first package to merge).
2. File a request to merge every package into the new split package.
3. Upload a proper split package to replace the meta package.
It is a bit unfortunate that this process makes merging a bit more complicated and results in packages being unavailable for a short transition period (see steps 1 to 3). I didn't come up with something better yet. Should we give TUs extra power and allow for uploading PKGBUILDs that automatically overwrite (and merge) packages? The downside is that this would be quite complicated to implement and we would have to ensure that no strange things can happen, e.g. partly overwriting another split package by replacing a subset of its packages. Trusted Users would also have to have a very close look at the packages before merging to ensure that no malicious takeover happens.
Any suggestions are welcome.
One thing to add is that if you own all the other packages, you can change their pkgname (to sth random) while keeping the same pkgbase. You can then upload the new package with all the pkgnames and let a TU to merge the original (not empty and useless) packages to the new one. This way at least it is not necessary to wait for a TU to make the new package work.
Thanks, artoo
On Sat, 31 May 2014 at 21:08:34, Yichao Yu wrote:
[...]
It is a bit unfortunate that this process makes merging a bit more complicated and results in packages being unavailable for a short transition period (see steps 1 to 3). I didn't come up with something better yet. Should we give TUs extra power and allow for uploading PKGBUILDs that automatically overwrite (and merge) packages? The downside is that this would be quite complicated to implement and we would have to ensure that no strange things can happen, e.g. partly overwriting another split package by replacing a subset of its packages. Trusted Users would also have to have a very close look at the packages before merging to ensure that no malicious takeover happens.
Any suggestions are welcome.
One thing to add is that if you own all the other packages, you can change their pkgname (to sth random) while keeping the same pkgbase. You can then upload the new package with all the pkgnames and let a TU to merge the original (not empty and useless) packages to the new one. This way at least it is not necessary to wait for a TU to make the new package work.
Good idea! Actually, that should already work: Just add a pkgbase variable to the PKGBUILDs and change their pkgname, e.g. by appending the string "-old". So, another (maybe better) work flow is: 1. Add pkgbase variables to each package using the current package name as package base name. 2. Change the pkgname of each package to something new, e.g. by adding the suffix "-old". 3. Upload the new split package. 4. File a request to merge the "-old" packages (more precisely: the old package bases that only contain one package with the suffix "-old") into the new split package.
Thanks, artoo
participants (3)
-
artux
-
Lukas Fleischer
-
Yichao Yu