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