Pacman

Historical bug tracker for the Pacman package manager.

The pacman bug tracker has moved to gitlab:
https://gitlab.archlinux.org/pacman/pacman/-/issues

This tracker remains open for interaction with historical bugs during the transition period. Any new bugs reports will be closed without further action.
Tasklist

FS#40118 - [pacman] makepkg ISO extraction to $srcdir

Attached to Project: Pacman
Opened by René Herman (rene) - Sunday, 27 April 2014, 21:49 GMT
Last edited by Allan McRae (Allan) - Wednesday, 30 April 2014, 05:53 GMT
Task Type Feature Request
Category makepkg
Status Assigned
Assigned To No-one
Architecture All
Severity Low
Priority Normal
Reported Version 4.1.2
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 0
Private No

Details

bsdtar as used by makepkg to unpack sources can also extract most ISO9660 images. With formats such as tar.gz it is generally expected that the archive contains a single top-directory (i.e., "foo-1.0.3.tar.gz" would unpack into a single top-level "foo-1.0.3" directory); exceptions generally mean that the archive comes from Windows.

For ISO images this is however never the expectation, meaning its root directory unpacks over all other files in the $srcdir; in an actual build just now, this caused me to have to rename local files. Given that the ISO expectancy is contrary to the regular unix archive expectancy, I believe it might make sense to single-out ISO to unpack into for example $srcdir/$volid/, with VOLID the ISO volume id.
This task depends upon

Comment by Dave Reisner (falconindy) - Monday, 28 April 2014, 02:54 GMT
This doesn't strike me as all that common of a thing. Perhaps it's sufficient to just add the ISO file to noextract() and deal with this on your own in prepare.
Comment by René Herman (rene) - Monday, 28 April 2014, 03:06 GMT
I agree that's an option, but given that the use of bsdtar/libarchive mostly makes ISO support transparent it's nicer if it then actually is, well, transparent. I haven't a clue about the pacman/makepkg innards; if it's fairly trivially done, I believe it's probably worth it. If not -- then not.

(could in fact be a reason to generically extend the source=filename::fileuri syntax with a ::dir suffix or similar; that also helps for those Windows-type ZIP archives without a top-level dir)
Comment by Allan McRae (Allan) - Wednesday, 30 April 2014, 05:53 GMT
  • Assignment removed
Unassigning me as it will be low, low, low on my priority list... I'll review a patch if anyone provides it.
Comment by Eli Schwartz (eschwartz) - Sunday, 29 April 2018, 13:54 GMT
Relevant: https://lists.archlinux.org/pipermail/pacman-dev/2018-April/022442.html

If we can use subdirs as part of a general sources syntax, then this will probably obviate the need for special-casing ISO files.

Loading...