[pacman-dev] makepkg and NOT extracting netfiles
Okay...blame wizzomafizzo :P. Because of the new way makepkg deals with files (not using the extension), files that are actually zipfiles but called something else that do not need to be extracted will be extracted (this is wizz's example). Best example I can think of is like a .pk3 file for some games (which I think is really just a zipfile). Anyway....we came up with the idea of a noextract=(...) field in the PKGBUILD and the patch is below. I'm not entirely too sure on whether or not this is entirely necessary...but oh well. Patch is below. ~ Jamie / yankees26 Signed-off-by: James Rosten <seinfeld90@gmail.com> Index: makepkg =================================================================== RCS file: /home/cvs-pacman/pacman-lib/scripts/makepkg,v retrieving revision 1.33 diff -u -r1.33 makepkg --- makepkg 22 Jan 2007 19:26:23 -0000 1.33 +++ makepkg 23 Jan 2007 05:34:25 -0000 @@ -425,7 +425,7 @@ unset pkgname pkgver pkgrel pkgdesc url license groups provides md5sums force unset replaces depends conflicts backup source install build makedepends -unset options +unset options noextract # some applications (eg, blackbox) will not build with some languages unset LC_ALL LANG @@ -680,7 +680,17 @@ msg "Extracting Sources..." for netfile in "${source[@]}"; do unziphack=0 + NoExtract=0 file=$(strip_url "$netfile") + for skipfile in "${noextract[@]}"; do + if [ "$skipfile" = "$file" ]; then + NoExtract=1 + break; + fi + done + if [ $NoExtract -eq 1 ]; then + continue; + fi # fix flyspray #6246 file_type=$(file -biz "$file") unset cmd
Hi, On Tue, Jan 23, 2007 at 12:40:21AM -0500, James Rosten wrote:
Okay...blame wizzomafizzo :P. Because of the new way makepkg deals with files (not using the extension), files that are actually zipfiles but called something else that do not need to be extracted will be extracted (this is wizz's example). Best example I can think of is like a .pk3 file for some games (which I think is really just a zipfile). Anyway....we came up with the idea of a noextract=(...) field in the PKGBUILD and the patch is below.
Very nice idea, indeed.
@@ -680,7 +680,17 @@ msg "Extracting Sources..." for netfile in "${source[@]}"; do unziphack=0 + NoExtract=0 file=$(strip_url "$netfile") + for skipfile in "${noextract[@]}"; do + if [ "$skipfile" = "$file" ]; then + NoExtract=1 + break; + fi + done + if [ $NoExtract -eq 1 ]; then + continue; + fi
Why do you invent camelcase here? Hannes
On 1/23/07, hannes <hannes@saeurebad.de> wrote:
Why do you invent camelcase here?
Well noextract was already taken, so I just named it NoExtract. Didn't think too much of it. ~ Jamie / yankees26
On 1/23/07, James Rosten <seinfeld90@gmail.com> wrote:
On 1/23/07, hannes <hannes@saeurebad.de> wrote:
Why do you invent camelcase here?
Well noextract was already taken, so I just named it NoExtract. Didn't think too much of it.
Merged with some minor changes - see the CVS commit message
On Tue, Jan 23, 2007 at 12:40:21AM -0500, James Rosten wrote:
unset LC_ALL LANG @@ -680,7 +680,17 @@ msg "Extracting Sources..." for netfile in "${source[@]}"; do unziphack=0 + NoExtract=0 file=$(strip_url "$netfile") + for skipfile in "${noextract[@]}"; do + if [ "$skipfile" = "$file" ]; then + NoExtract=1 + break; + fi + done + if [ $NoExtract -eq 1 ]; then + continue; + fi # fix flyspray #6246 file_type=$(file -biz "$file")
file-pattern-only was much clearer. You never want to extract JAR files). Awesome. Much complexity just to guess right how the package maintainer wants to prepare the sources. This should be moved into a single function lookIntoTheCrystalBallAndExtractSources(). Not really KISS. What about reverting to the old default behaviour and making source extraction part of the maintainers build() function or provide a default prep() function (too keep older PKGBUILDs working) which is called before build() and let the maintainer redefine prep() to override the default behaviour. Jürgen
Hi Juergen, On Tue, Jan 23, 2007 at 06:02:30PM +0100, J?rgen H?tzel wrote:
What about reverting to the old default behaviour and making source extraction part of the maintainers build() function or provide a default prep() function (too keep older PKGBUILDs working) which is called before build() and let the maintainer redefine prep() to override the default behaviour.
If KISS, then properly ;) Overriding a prep() function seems a bit ugly, totally manual extraction would be best I guess. Mostly just a `tar xf filename', no big thing. Hannes -- http://saeurebad.de/~hannes/
On Tue, 23 Jan 2007 18:48:45 +0100 Johannes Weiner <hannes@saeurebad.de> wrote:
If KISS, then properly ;) Overriding a prep() function seems a bit ugly, totally manual extraction would be best I guess.
Mostly just a `tar xf filename', no big thing.
Except that if we move to totally manual extraction, every PKGBUILD currently existing would have to change - this becomes a bit more of a big thing now. ;) I like the 'noextract' option - there have been a couple packages I've built with .zip archives that, when auto-extracted, dumped their contents straight into $startdir/src which annoyed me 'cause then the extracted files got mixed in with the patches and whatnot - I could see a noextract making things a bit clearer here - "noextract" the zip, then in the build() properly extract it all to a seperate subdir. -- Travis
On 1/23/07, Jürgen Hötzel <juergen@hoetzel.info> wrote:
Awesome. Much complexity just to guess right how the package maintainer wants to prepare the sources. This should be moved into a single function lookIntoTheCrystalBallAndExtractSources(). Not really KISS.
Not true. I added all of 3 lines to get this functionality. Considering "noextract" is a very rare case, I think this is fairly KISS in nature. All existing PKGBUILDs work the same way, add some noextract=(foo) entries and your files aren't extracted. I'm not entirely sure what you see as complex about that. Also, manual extraction is not very "KISS" either... if things are obvious, they should be handled in an obvious manner (extract a tar.gz file).
On Tue, Jan 23, 2007 at 12:15:14PM -0600, Aaron Griffin wrote:
On 1/23/07, Jürgen Hötzel <juergen@hoetzel.info> wrote:
Awesome. Much complexity just to guess right how the package maintainer wants to prepare the sources. This should be moved into a single function lookIntoTheCrystalBallAndExtractSources(). Not really KISS.
Not true. I added all of 3 lines to get this functionality. Considering "noextract" is a very rare case, I think this is fairly
I meant the whole 42 lines in makepkg required to "guess how to extract" the sources.
Also, manual extraction is not very "KISS" either... if things are obvious, they should be handled in an obvious manner (extract a tar.gz file).
Nearly every build() function starts with a "cd $startdir/src/$pkgname-$pkgver" you could also move this (for the same reason) to makepkg but will have the same error-prone workarounds. Jürgen
On 1/23/07, Jürgen Hötzel <juergen@hoetzel.info> wrote:
On Tue, Jan 23, 2007 at 12:15:14PM -0600, Aaron Griffin wrote:
On 1/23/07, Jürgen Hötzel <juergen@hoetzel.info> wrote:
Awesome. Much complexity just to guess right how the package maintainer wants to prepare the sources. This should be moved into a single function lookIntoTheCrystalBallAndExtractSources(). Not really KISS.
Not true. I added all of 3 lines to get this functionality. Considering "noextract" is a very rare case, I think this is fairly
I meant the whole 42 lines in makepkg required to "guess how to extract" the sources.
Didn't it get shorter with this change?
Also, manual extraction is not very "KISS" either... if things are obvious, they should be handled in an obvious manner (extract a tar.gz file).
Nearly every build() function starts with a
"cd $startdir/src/$pkgname-$pkgver"
you could also move this (for the same reason) to makepkg but will have the same error-prone workarounds.
The only other possibility- and of course it still has its drawbacks- would be to just do a "noextract" option in the options array, and if it was set, it is up to the package itself to do the extraction. However, this becomes a pain when there is only one file you may not want extracted, and then are required to manually extract the rest, so I don't know if that is any better. No matter what we do here, we are always left with some issue, and if we went way back the original fie extension way, we are still left with the "wrong extension on archive" issue. -Dan
participants (7)
-
Aaron Griffin
-
Dan McGee
-
hannes＠saeurebad.de
-
James Rosten
-
Johannes Weiner
-
Jürgen Hötzel
-
Travis Willard