FS#10516 - Support for 'stick' option in PKGBUILDs

Attached to Project: Pacman
Opened by Alessio Bolognino (mOLOk) - Monday, 26 May 2008, 23:30 GMT
Last edited by Dan McGee (toofishes) - Thursday, 24 July 2008, 02:29 GMT
Task Type Feature Request
Category General
Status Closed
Assigned To No-one
Architecture All
Severity Very Low
Priority Normal
Reported Version 3.1.3
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

While browsing Frugalware's repos I noticed that they have in FrugalBuilds an option that seems useful: it's called "stick"; As far as I understood, it is more or less the opposite of "force", that means that if a package has the "stick" option it is not updated automatically, even if its $pkgver-$pkgrel is > than the one installed.
Example of use:
Developers found out that all packages in [extra] don't have the right license, but at the same time they don't want the users to download a lot of packages for such a minor change like that.
Solution: fix the licenses in the packages, bump the pkgrel and add the stick option. When there is a new release of the software, just bump the pkgver and remove the stick option.
This task depends upon

Closed by  Dan McGee (toofishes)
Thursday, 24 July 2008, 02:29 GMT
Reason for closing:  Won't implement
Additional comments about closing:  For now, won't implement. I understand the idea and can see its usefulness, but I think it introduces another point of failure (forgetting to remove this special flag when doing real rebuilds).
Comment by Aaron Griffin (phrakture) - Tuesday, 27 May 2008, 06:43 GMT
We try to manage these things at the repo level - changes like licenses are done in the trunk of each package checkout, and may not be merged into the actual real PKGBUILD until the next time it is changed.
Comment by Alessio Bolognino (mOLOk) - Tuesday, 27 May 2008, 13:56 GMT
Yeah, that's right; anyway let me try to explain a little better when this is useful:
aalib-1.0-1 has a minor error, like the wrong $url, so the maintainer fix it and release aalib-1.0-2 WITH the stick option; if user1 already have aalib-1.0-1 installed on his machine, then pacman won't update to aalib-1.0-2 (unless user1 explicitly tells pacman to do it), but when user2, who doesn't have aalib-1.0-1 installed, tells pacman to install aalib, pacman installs aalib-1.0-2. This way user1 didn't have to download the whole new aalib for a minor change, but user2 has the fixed package.

Doing what you usually do now, user2 would have still aalib-1.0-1 installed. Not a huge problem, I agree, but maybe someone think this feature is cool and want to implement it.

In b4, patches welcome :)

Comment by Nagy Gabor (combo) - Tuesday, 27 May 2008, 15:10 GMT
If I understood correctly Aaron's standpoint, AL doesn't release new version in order to fix such a small thing, they fix minor issues in the next 'real' release instead. Right?
Comment by Aaron Griffin (phrakture) - Tuesday, 27 May 2008, 17:29 GMT
That's correct. Not saying this is a bad idea, I just don't think we'd get a lot of use out of it because of the way we do these things.
Comment by Nagy Gabor (combo) - Tuesday, 27 May 2008, 17:52 GMT
I also feel that 'stick' option is a bit paradox. If the old version is good for upgraders, this also means that it is good for -S users... And I think this "invisible" flag would cause more bug than benefit (developer forgets to revoke this flag etc.)
Comment by Xavier (shining) - Monday, 02 June 2008, 08:47 GMT
I see how this option could be useful, but as Nagy said, it would be more complexity, so potentially more problems and bugs, and as Aaron said, the current way of managing these at repo level seems good enough. So "won't implement" ?
Comment by Allan McRae (Allan) - Tuesday, 03 June 2008, 09:07 GMT
Another distro using pacman might find it useful if their system works a bit differently to Arch. But I would close this with a "won't implement" and if another distro comes along wanting it then reconsider.

Loading...