FS#20826 - Add complete pkgname array to split package's .PKGINFO

Attached to Project: Pacman
Opened by Pierre Schmitz (Pierre) - Sunday, 12 September 2010, 16:30 GMT
Last edited by Allan McRae (Allan) - Friday, 09 September 2011, 09:30 GMT
Task Type Feature Request
Category makepkg
Status Closed
Assigned To Dan McGee (toofishes)
Allan McRae (Allan)
Architecture All
Severity Low
Priority Normal
Reported Version 3.4.0
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

All split packages which were build with the same PKGBUILD share the same pkgbase in their .PKGINFO file. But one direction is missing: Giving a single split package file one cannot tell which other packages were build with the same PKGBUILD.

The solution would be somehow add the complete list of pkgnames to each package's .PKGINFO file. I am only unsure about the key one should use here and whether this list should include the package's own pkgname or not.

ATM I see two possible usages for this information:
* check whether a split package is missing in the staging dir on db-update
* check whether a split package has been removed on db-update

The second task would even be muh easier if that information would also be put into the db files. (pacman might use this information, too) This might be redundant though as one could also get the same information by scanning the db file for a given pkgbase and output the related pkgname.
This task depends upon

Closed by  Allan McRae (Allan)
Friday, 09 September 2011, 09:30 GMT
Reason for closing:  No response
Comment by Allan McRae (Allan) - Monday, 13 September 2010, 00:26 GMT
@Dan: any opinion on this?
Comment by Dan McGee (toofishes) - Monday, 13 September 2010, 00:31 GMT
I'm not particularly fond of it, but I'm not sure that actually has any good reasoning behind it. It seems unnecessary as this info is available elsewhere or something.

Both use cases can be solved by simply looking at the PKGBUILD in SVN, no?
Comment by Allan McRae (Allan) - Monday, 27 June 2011, 08:36 GMT
@Pierre: is this still something that would be useful?

Loading...