[arch-dev-public] [Bug] db-scripts fail to remove split package
I made this change to the kernel26 PKGBUILD: http://repos.archlinux.org/wsvn/packages/?op=comp&compare[]=%2Fkernel26%2Ftrunk@80408&compare[]=%2Fkernel26%2Ftrunk%2F@81433 However, db-testing fails to remove the kernel26-firmware package. I need to remove it manually.
On Sat, 19 Jun 2010 14:09:40 +0200, Thomas Bächler <thomas@archlinux.org> wrote:
I made this change to the kernel26 PKGBUILD:
However, db-testing fails to remove the kernel26-firmware package. I need to remove it manually.
At first: Please use the bug tracker. db-update cannot know about this change. It only adds packages to the repo. And I don't think it would be the right place to implement this as it would need to scan all packages on every update for the same pkgbase and see if it is still present in the PKGBUILD. The ftpdir-cleanup cron only removes packages that are no longer in the package db; but it does not remove packages from the db itself. It could be implemented here, but it would increase the already quite long runtime of that cron. So if you remove split packages in the PKGBUILD you also have to remove it from the db. Maybe someone could write a patch for check_packages.py to detect such orphaned packages. My suggestion: Packages should be removed only manually from the DB. But the check-script could be enhanced to detect such packages. -- Pierre Schmitz, https://users.archlinux.de/~pierre
On 19/06/10 22:27, Pierre Schmitz wrote:
On Sat, 19 Jun 2010 14:09:40 +0200, Thomas Bächler<thomas@archlinux.org> wrote:
I made this change to the kernel26 PKGBUILD:
However, db-testing fails to remove the kernel26-firmware package. I need to remove it manually.
At first: Please use the bug tracker.
db-update cannot know about this change. It only adds packages to the repo. And I don't think it would be the right place to implement this as it would need to scan all packages on every update for the same pkgbase and see if it is still present in the PKGBUILD.
The ftpdir-cleanup cron only removes packages that are no longer in the package db; but it does not remove packages from the db itself. It could be implemented here, but it would increase the already quite long runtime of that cron.
So if you remove split packages in the PKGBUILD you also have to remove it from the db. Maybe someone could write a patch for check_packages.py to detect such orphaned packages.
My suggestion: Packages should be removed only manually from the DB. But the check-script could be enhanced to detect such packages.
My guess is the check screk already detects them. We got errors about xz-utils and pkgconfig when they were renamed and the old versions removed from SVN. Allan
On Sat, 19 Jun 2010 22:36:35 +1000, Allan McRae <allan@archlinux.org> wrote:
On 19/06/10 22:27, Pierre Schmitz wrote:
So if you remove split packages in the PKGBUILD you also have to remove it from the db. Maybe someone could write a patch for check_packages.py to detect such orphaned packages.
My suggestion: Packages should be removed only manually from the DB. But the check-script could be enhanced to detect such packages.
My guess is the check screk already detects them. We got errors about xz-utils and pkgconfig when they were renamed and the old versions removed from SVN.
I think this only checks if a packages was completely removed from svn but not if a split package was removed from the PKGBUILD. -- Pierre Schmitz, https://users.archlinux.de/~pierre
On Sat, Jun 19, 2010 at 7:27 AM, Pierre Schmitz <pierre@archlinux.de> wrote:
On Sat, 19 Jun 2010 14:09:40 +0200, Thomas Bächler <thomas@archlinux.org> wrote:
I made this change to the kernel26 PKGBUILD:
However, db-testing fails to remove the kernel26-firmware package. I need to remove it manually.
At first: Please use the bug tracker.
db-update cannot know about this change. It only adds packages to the repo. And I don't think it would be the right place to implement this as it would need to scan all packages on every update for the same pkgbase and see if it is still present in the PKGBUILD.
The ftpdir-cleanup cron only removes packages that are no longer in the package db; but it does not remove packages from the db itself. It could be implemented here, but it would increase the already quite long runtime of that cron.
So if you remove split packages in the PKGBUILD you also have to remove it from the db. Maybe someone could write a patch for check_packages.py to detect such orphaned packages.
My suggestion: Packages should be removed only manually from the DB. But the check-script could be enhanced to detect such packages.
This is how it was intended: removing packages requires db-remove. In order to do it any other way, we would need to scan all PKGBUILDs (we do this in the cleanup script already, I think), grab the split names + versions, and then remove those items from a list of everything in the dir. Anything remaining gets db-removed. It sounds tedious and messy though
Am 21.06.2010 20:39, schrieb Aaron Griffin:
This is how it was intended: removing packages requires db-remove.
In order to do it any other way, we would need to scan all PKGBUILDs (we do this in the cleanup script already, I think), grab the split names + versions, and then remove those items from a list of everything in the dir. Anything remaining gets db-removed.
It sounds tedious and messy though
Can you db-remove a package that is not found in SVN? I used repo-remove on the db file manually now.
On Mon, Jun 21, 2010 at 2:58 PM, Thomas Bächler <thomas@archlinux.org> wrote:
Am 21.06.2010 20:39, schrieb Aaron Griffin:
This is how it was intended: removing packages requires db-remove.
In order to do it any other way, we would need to scan all PKGBUILDs (we do this in the cleanup script already, I think), grab the split names + versions, and then remove those items from a list of everything in the dir. Anything remaining gets db-removed.
It sounds tedious and messy though
Can you db-remove a package that is not found in SVN? I used repo-remove on the db file manually now.
I believe so. It should still try to remove it from SVN, but I don't think it's a process-stopping error if it fails
participants (4)
-
Aaron Griffin
-
Allan McRae
-
Pierre Schmitz
-
Thomas Bächler