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 > >> >