[pacman-dev] Move package to cache when installed with -U
Hey, So I would be interested in such a feature, and I found it being rejected as FS#15143, but I have some questions. It seems the main reason it was rejected was this: " My second argument against this is that users sometimes do local rebuild of official packages, and maybe don't want to mix these packages with official ones in the cache (which could cause integrity check failures next time they upgrade their system). " And I don't understand. Why/how would there be an integrity check failure on upgrade ? I thought integrity check meant that the package(s) about to be installed was being checked. So, during an upgrade, there would be no reason to check this already installed package, no? And if there was an update available, it's the integrity of the newly downloaded package that would be checked, and it would have no reason to fail. What am I not understanding/misunderstanding here? Because I do like this idea and, unless there is an inherent problem with it of course, I might be interested into looking to make a patch to add such an option. Thanks, -jacky Ref: https://bugs.archlinux.org/task/15143
On Wed, Feb 15, 2012 at 7:39 AM, jjacky <i.am.jack.mail@gmail.com> wrote:
Hey,
So I would be interested in such a feature, and I found it being rejected as FS#15143, but I have some questions.
It seems the main reason it was rejected was this:
" My second argument against this is that users sometimes do local rebuild of official packages, and maybe don't want to mix these packages with official ones in the cache (which could cause integrity check failures next time they upgrade their system). "
And I don't understand. Why/how would there be an integrity check failure on upgrade ?
I thought integrity check meant that the package(s) about to be installed was being checked. So, during an upgrade, there would be no reason to check this already installed package, no?
And if there was an update available, it's the integrity of the newly downloaded package that would be checked, and it would have no reason to fail.
What am I not understanding/misunderstanding here?
Because I do like this idea and, unless there is an inherent problem with it of course, I might be interested into looking to make a patch to add such an option.
Every time you rebuild a package, the md5sum, sha256sum, and PGP signature would be different on the resulting file. If I build foobar-1.0-1 from ABS without bumping the pkgrel, it doesn't matter whether I tweak anything in the PKGBUILD or not, the package file produced is different. If I install that with -U, I'm likely OK- we have no md5 or sha256 checksum to use, and likely no errant .sig file in the same directory. However, if I try to reinstall a package with -S that I've rebuilt locally, fireworks and failure will result- neither the checksums nor the PGP signature in the sync database will match your rebuilt package that has been cached rather than the real one. -Dan
On 02/15/12 14:53, Dan McGee wrote:
On Wed, Feb 15, 2012 at 7:39 AM, jjacky <i.am.jack.mail@gmail.com> wrote:
Hey,
So I would be interested in such a feature, and I found it being rejected as FS#15143, but I have some questions.
It seems the main reason it was rejected was this:
" My second argument against this is that users sometimes do local rebuild of official packages, and maybe don't want to mix these packages with official ones in the cache (which could cause integrity check failures next time they upgrade their system). "
And I don't understand. Why/how would there be an integrity check failure on upgrade ?
I thought integrity check meant that the package(s) about to be installed was being checked. So, during an upgrade, there would be no reason to check this already installed package, no?
And if there was an update available, it's the integrity of the newly downloaded package that would be checked, and it would have no reason to fail.
What am I not understanding/misunderstanding here?
Because I do like this idea and, unless there is an inherent problem with it of course, I might be interested into looking to make a patch to add such an option.
Every time you rebuild a package, the md5sum, sha256sum, and PGP signature would be different on the resulting file.
If I build foobar-1.0-1 from ABS without bumping the pkgrel, it doesn't matter whether I tweak anything in the PKGBUILD or not, the package file produced is different.
If I install that with -U, I'm likely OK- we have no md5 or sha256 checksum to use, and likely no errant .sig file in the same directory.
However, if I try to reinstall a package with -S that I've rebuilt locally, fireworks and failure will result- neither the checksums nor the PGP signature in the sync database will match your rebuilt package that has been cached rather than the real one.
Ok, I think I got it. But that means it would only happen if one was to do a pacman -S foobar (after having compiled/-U that package), right? I thought the "would case failure on next upgrade" meant upgrading the package to a new version, or even just the next -Syu, but that is not the case. So to have the failure, one would need to: - build a package and install it (-U) w/out changing its name (and have that new option to copy local packages to the cache of course) - then, decide to "restore" the original package, through a -S Well, in that case I don't really see that as a problem. If one does do that, the error is to be expected after all. (And easy to fix: remove the file from the cache) Do you feel that because of this, having an option in pacman.conf to copy files installed with -U to the cache is a bad idea? Besides, I was thinking anyway that when this copy to the cache occurs, pacman would first check if there's already a file by that name in there, and if so ask whether to overwrite it or not. Which means, if one says yes in such a case, knowingly replacing the official package with their own rebuild in the cache, I'd say they must be ready to face the consequences. -j
-Dan
On Wed, Feb 15, 2012 at 10:53 AM, jjacky <i.am.jack.mail@gmail.com> wrote:
Ok, I think I got it. But that means it would only happen if one was to do a pacman -S foobar (after having compiled/-U that package), right? Yes, one would have to do that, unless...
I thought the "would case failure on next upgrade" meant upgrading the package to a new version, or even just the next -Syu, but that is not the case. I was a smart local packager and bumped the pkgrel of the package I rebuilt, and then when a new version shows up in the repos, my version that I built locally now collides with the version that is in the sync repos. Normally this wouldn't be reinstalled, but it could be if someone set it as an explicit target.
So to have the failure, one would need to: - build a package and install it (-U) w/out changing its name (and have that new option to copy local packages to the cache of course) - then, decide to "restore" the original package, through a -S
Well, in that case I don't really see that as a problem. If one does do that, the error is to be expected after all. (And easy to fix: remove the file from the cache)
Do you feel that because of this, having an option in pacman.conf to copy files installed with -U to the cache is a bad idea? If we do this, there will be no option involved, we do not need yet another silly knob to tweak. I'm mixed on whether this is a good move, but I'm a -1 on adding any sort of option.
Besides, I was thinking anyway that when this copy to the cache occurs, pacman would first check if there's already a file by that name in there, and if so ask whether to overwrite it or not. Callbacks already suck; adding another one is also a -1 from me.
Which means, if one says yes in such a case, knowingly replacing the official package with their own rebuild in the cache, I'd say they must be ready to face the consequences. When you're manning the support desk around here, you can make that call, but until then, we like to not have to close bugs every time preventable problems like this get reported.
Pro tip, to show that this really isn't a big deal at all and there is already a workaround: just add 'file://' to your path and be done with it. Bam, the downloader kicks in, copies it to your local package cache, and off you go. No new option necessary, no new code, it works today. -Dan
On 02/15/12 23:36, Dan McGee wrote:
On Wed, Feb 15, 2012 at 10:53 AM, jjacky <i.am.jack.mail@gmail.com> wrote:
Ok, I think I got it. But that means it would only happen if one was to do a pacman -S foobar (after having compiled/-U that package), right? Yes, one would have to do that, unless...
I thought the "would case failure on next upgrade" meant upgrading the package to a new version, or even just the next -Syu, but that is not the case. I was a smart local packager and bumped the pkgrel of the package I rebuilt, and then when a new version shows up in the repos, my version that I built locally now collides with the version that is in the sync repos. Normally this wouldn't be reinstalled, but it could be if someone set it as an explicit target.
So to have the failure, one would need to: - build a package and install it (-U) w/out changing its name (and have that new option to copy local packages to the cache of course) - then, decide to "restore" the original package, through a -S
Well, in that case I don't really see that as a problem. If one does do that, the error is to be expected after all. (And easy to fix: remove the file from the cache)
Do you feel that because of this, having an option in pacman.conf to copy files installed with -U to the cache is a bad idea? If we do this, there will be no option involved, we do not need yet another silly knob to tweak. I'm mixed on whether this is a good move, but I'm a -1 on adding any sort of option.
Besides, I was thinking anyway that when this copy to the cache occurs, pacman would first check if there's already a file by that name in there, and if so ask whether to overwrite it or not. Callbacks already suck; adding another one is also a -1 from me.
Which means, if one says yes in such a case, knowingly replacing the official package with their own rebuild in the cache, I'd say they must be ready to face the consequences. When you're manning the support desk around here, you can make that call, but until then, we like to not have to close bugs every time preventable problems like this get reported.
Pro tip, to show that this really isn't a big deal at all and there is already a workaround: just add 'file://' to your path and be done with it. Bam, the downloader kicks in, copies it to your local package cache, and off you go. No new option necessary, no new code, it works today.
Oh, nice. Didn't realize this was possible for some reason, thanks. Yeah that'll work fine. -j
-Dan
participants (2)
-
Dan McGee
-
jjacky