[pacman-dev] [PATCH] makepkg: Add '--nocompress' syntactic sugar
Compression is a waste of time when building a package for local installation. It could already be suppressed easily, but not yet via an argument to makepkg. Signed-off-by: Jouke Witteveen <j.witteveen@gmail.com> --- The OPT_LONG array should probably be reformatted, but that could as well happen separately. At any rate it is not clear to me what the guiding principles would be. doc/makepkg.8.asciidoc | 4 ++++ scripts/completion/bash_completion.in | 4 ++-- scripts/makepkg.sh.in | 4 +++- 3 files changed, 9 insertions(+), 3 deletions(-) diff --git a/doc/makepkg.8.asciidoc b/doc/makepkg.8.asciidoc index 544659fc..86e1960a 100644 --- a/doc/makepkg.8.asciidoc +++ b/doc/makepkg.8.asciidoc @@ -165,6 +165,10 @@ Options *\--nocheck*:: Do not run the check() function in the PKGBUILD or handle the checkdepends. +*\--nocompress*:: + Do not compress the package. Equivalent to setting PKGEXT=".pkg.tar" and + SRCEXT=".src.tar". + *\--noprepare*:: Do not run the prepare() function in the PKGBUILD. diff --git a/scripts/completion/bash_completion.in b/scripts/completion/bash_completion.in index a1ab9fec..30d5c683 100644 --- a/scripts/completion/bash_completion.in +++ b/scripts/completion/bash_completion.in @@ -80,8 +80,8 @@ _makepkg() { elif [[ ! $prev =~ ^-(-(config|help|key|version)$|\w*[Vh]) ]]; then opts=('allsource asdeps check clean cleanbuild config force geninteg help holdver ignorearch install key log needed noarchive nobuild nocheck - nocolor noconfirm nodeps noextract noprepare noprogressbar nosign - packagelist printsrcinfo repackage rmdeps sign skipchecksums + nocolor nocompress noconfirm nodeps noextract noprepare noprogressbar + nosign packagelist printsrcinfo repackage rmdeps sign skipchecksums skipinteg skippgpcheck source syncdeps verifysource version' 'A C L R S c d e f g h i m o p r s') _arch_ptr2comp opts diff --git a/scripts/makepkg.sh.in b/scripts/makepkg.sh.in index 4d9948ec..953b5e36 100644 --- a/scripts/makepkg.sh.in +++ b/scripts/makepkg.sh.in @@ -977,6 +977,7 @@ usage() { printf -- "$(gettext " --key <key> Specify a key to use for %s signing instead of the default")\n" "gpg" printf -- "$(gettext " --noarchive Do not create package archive")\n" printf -- "$(gettext " --nocheck Do not run the %s function in the %s")\n" "check()" "$BUILDSCRIPT" + printf -- "$(gettext " --nocompress Do not compress the package archive")\n" printf -- "$(gettext " --noprepare Do not run the %s function in the %s")\n" "prepare()" "$BUILDSCRIPT" printf -- "$(gettext " --nosign Do not create a signature for the package")\n" printf -- "$(gettext " --packagelist Only list package filepaths that would be produced")\n" @@ -1026,7 +1027,7 @@ ARGLIST=("$@") OPT_SHORT="AcCdefFghiLmop:rRsSV" OPT_LONG=('allsource' 'check' 'clean' 'cleanbuild' 'config:' 'force' 'geninteg' 'help' 'holdver' 'ignorearch' 'install' 'key:' 'log' 'noarchive' 'nobuild' - 'nocolor' 'nocheck' 'nodeps' 'noextract' 'noprepare' 'nosign' 'packagelist' + 'nocolor' 'nocheck' 'nocompress' 'nodeps' 'noextract' 'noprepare' 'nosign' 'packagelist' 'printsrcinfo' 'repackage' 'rmdeps' 'sign' 'skipchecksums' 'skipinteg' 'skippgpcheck' 'source' 'syncdeps' 'verifysource' 'version') @@ -1067,6 +1068,7 @@ while true; do -m|--nocolor) USE_COLOR='n'; PACMAN_OPTS+=("--color" "never") ;; --noarchive) NOARCHIVE=1 ;; --nocheck) RUN_CHECK='n' ;; + --nocompress) PKGEXT=".pkg.tar"; SRCEXT=".src.tar";; --noprepare) RUN_PREPARE='n' ;; --nosign) SIGNPKG='n' ;; -o|--nobuild) BUILDPKG=0 NOBUILD=1 ;; -- 2.21.0
On 18/5/19 9:34 pm, Jouke Witteveen wrote:
Compression is a waste of time when building a package for local installation. It could already be suppressed easily, but not yet via an argument to makepkg.
As it could already be suppressed easily (makepkg.conf and with an environmental variable), we don't need an option. A
On Sat, May 18, 2019 at 1:54 PM Allan McRae <allan@archlinux.org> wrote:
On 18/5/19 9:34 pm, Jouke Witteveen wrote:
Compression is a waste of time when building a package for local installation. It could already be suppressed easily, but not yet via an argument to makepkg.
As it could already be suppressed easily (makepkg.conf and with an environmental variable), we don't need an option.
makepkg.conf is of course unsuitable for one-off package building without compression. The environmental variable has different ergonomics and discoverability. With the proposed patch, the semantics are simplified: Use --nocompress if you want no compression, versus remembering to use PKGEXT and what value to set it too. The patch pulls this logic inside makepkg and adds it to the documentation (manpage, bash-completion, and --help). I'd say there is some definite value in the few extra lines this adds. Anyway, thanks for your quick response! - Jouke
On 5/18/19 8:01 AM, Jouke Witteveen wrote:
On Sat, May 18, 2019 at 1:54 PM Allan McRae <allan@archlinux.org> wrote:
On 18/5/19 9:34 pm, Jouke Witteveen wrote:
Compression is a waste of time when building a package for local installation. It could already be suppressed easily, but not yet via an argument to makepkg.
As it could already be suppressed easily (makepkg.conf and with an environmental variable), we don't need an option.
makepkg.conf is of course unsuitable for one-off package building without compression. The environmental variable has different ergonomics and discoverability.
I agree with Allan that this is unnecessary. My assumption is that anyone interested in disabling compression will be interested in doing so for many packages, not just one -- the use case would presumably be for building custom packages for personal use, where: - disk space is usually not an issue - bandwidth is unaffected since it is never traveling over the network - the cpu cycles and wait time for compression are thus not worth it And in this case, it is equally true that you never want compression, whether you only intend to build one package ever, or not.
With the proposed patch, the semantics are simplified: Use --nocompress if you want no compression, versus remembering to use PKGEXT and what value to set it too.
The semantics become more complicated, because there are now three places to disable compression rather than two, and one of those places *only* disables compresion, while the other two are also useful to choose a compression type. IMHO the current semantics are clearer, because the two places that it can be set are both defined as "choose a compression type, including 'no compression'"
The patch pulls this logic inside makepkg and adds it to the documentation (manpage, bash-completion, and --help). I'd say there is some definite value in the few extra lines this adds.
Anyway, thanks for your quick response! - Jouke
I don't think the argument should be about the number of lines it adds. Useful functionality should not be rejected for size issues except in extreme cases, and makepkg can definitely afford 284 bytes. The issue I see is the increased surface this adds, the fact that the --help text becomes longer (it already has enough options that even the short help text does not completely fit on my screen), the minor cognitive burden of deducing which of several ways to specify a thing will take precedence if all of them are being used. I'm not saying this is a major blocker, but it is definitely a consideration of some sort, and I don't currently believe there is a compelling argument that adding this syntactic sugar for an existing feature is sufficiently useful to justify yet another option. ... Implementation-wise, if I was passing a command-line option I would expect it to work always, no matter what, with absolutely no exceptions. For example, if I pass --nocheck, I expect that to override makepkg.conf's BUILDENV setting, and in fact, makepkg has a separate state variable to determine whether it is explicitly overridden on the command line ($RUN_CHECK) or set via makepkg.conf (the check_buildenv() function): if [[ $RUN_CHECK = 'y' ]] || { ! check_buildenv "check" "n" && [[ $RUN_CHECK != "n" ]]; } Where this matters is for PKGBUILDs that have (unwisely) set this in the PKGBUILD itself. No matter how odd it is to do so, it should still be graded with the priority of a makepkg.conf setting, and not override an explicit command line option. This assumption holds true for --check/--nocheck, and does not hold true for your suggested --nocompress. It also matters if someone sets an environment override, e.g. makepkg CC=clang makepkg has little-known behavior modeled after `make` in this regard. Your suggested implementation relies on the fact that makepkg performs option parsing before sourcing makepkg.conf, and that it backs up and restores the PKGEXT variable from the environment in order to preserve it. This results in the --nocompress option acting identical to setting the environment variable. But it is worth less than `extra_environment`. While I do not "expect" people to use the very confusing command line invocation: makepkg --nocompress PKGEXT=.pkg.tar.xz I would prefer that if we were to do this, we be consistent in how we handle it. -- Eli Schwartz Bug Wrangler and Trusted User
On Sun, May 19, 2019 at 5:01 AM Eli Schwartz <eschwartz@archlinux.org> wrote:
On 5/18/19 8:01 AM, Jouke Witteveen wrote:
On Sat, May 18, 2019 at 1:54 PM Allan McRae <allan@archlinux.org> wrote:
On 18/5/19 9:34 pm, Jouke Witteveen wrote:
Compression is a waste of time when building a package for local installation. It could already be suppressed easily, but not yet via an argument to makepkg.
As it could already be suppressed easily (makepkg.conf and with an environmental variable), we don't need an option.
makepkg.conf is of course unsuitable for one-off package building without compression. The environmental variable has different ergonomics and discoverability.
I agree with Allan that this is unnecessary.
My assumption is that anyone interested in disabling compression will be interested in doing so for many packages, not just one -- the use case would presumably be for building custom packages for personal use, where: - disk space is usually not an issue - bandwidth is unaffected since it is never traveling over the network - the cpu cycles and wait time for compression are thus not worth it
And in this case, it is equally true that you never want compression, whether you only intend to build one package ever, or not.
With the proposed patch, the semantics are simplified: Use --nocompress if you want no compression, versus remembering to use PKGEXT and what value to set it too.
The semantics become more complicated, because there are now three places to disable compression rather than two, and one of those places *only* disables compresion, while the other two are also useful to choose a compression type.
IMHO the current semantics are clearer, because the two places that it can be set are both defined as "choose a compression type, including 'no compression'"
The patch pulls this logic inside makepkg and adds it to the documentation (manpage, bash-completion, and --help). I'd say there is some definite value in the few extra lines this adds.
Anyway, thanks for your quick response! - Jouke
I don't think the argument should be about the number of lines it adds. Useful functionality should not be rejected for size issues except in extreme cases, and makepkg can definitely afford 284 bytes.
The issue I see is the increased surface this adds, the fact that the --help text becomes longer (it already has enough options that even the short help text does not completely fit on my screen), the minor cognitive burden of deducing which of several ways to specify a thing will take precedence if all of them are being used.
I'm not saying this is a major blocker, but it is definitely a consideration of some sort, and I don't currently believe there is a compelling argument that adding this syntactic sugar for an existing feature is sufficiently useful to justify yet another option.
...
Implementation-wise, if I was passing a command-line option I would expect it to work always, no matter what, with absolutely no exceptions. For example, if I pass --nocheck, I expect that to override makepkg.conf's BUILDENV setting, and in fact, makepkg has a separate state variable to determine whether it is explicitly overridden on the command line ($RUN_CHECK) or set via makepkg.conf (the check_buildenv() function):
if [[ $RUN_CHECK = 'y' ]] || { ! check_buildenv "check" "n" && [[ $RUN_CHECK != "n" ]]; }
Where this matters is for PKGBUILDs that have (unwisely) set this in the PKGBUILD itself. No matter how odd it is to do so, it should still be graded with the priority of a makepkg.conf setting, and not override an explicit command line option. This assumption holds true for --check/--nocheck, and does not hold true for your suggested --nocompress.
It also matters if someone sets an environment override, e.g.
makepkg CC=clang
makepkg has little-known behavior modeled after `make` in this regard. Your suggested implementation relies on the fact that makepkg performs option parsing before sourcing makepkg.conf, and that it backs up and restores the PKGEXT variable from the environment in order to preserve it. This results in the --nocompress option acting identical to setting the environment variable. But it is worth less than `extra_environment`. While I do not "expect" people to use the very confusing command line invocation:
makepkg --nocompress PKGEXT=.pkg.tar.xz
I would prefer that if we were to do this, we be consistent in how we handle it.
-- Eli Schwartz
Wow, thanks for this detailed response! This helps a lot with my understanding. - Jouke
On 5/19/19 3:20 PM, Jouke Witteveen wrote:
On Sun, May 19, 2019 at 5:01 AM Eli Schwartz <eschwartz@archlinux.org> wrote:
On 5/18/19 8:01 AM, Jouke Witteveen wrote:
On Sat, May 18, 2019 at 1:54 PM Allan McRae <allan@archlinux.org> wrote:
On 18/5/19 9:34 pm, Jouke Witteveen wrote:
Compression is a waste of time when building a package for local installation. It could already be suppressed easily, but not yet via an argument to makepkg.
As it could already be suppressed easily (makepkg.conf and with an environmental variable), we don't need an option.
makepkg.conf is of course unsuitable for one-off package building without compression. The environmental variable has different ergonomics and discoverability.
I agree with Allan that this is unnecessary.
My assumption is that anyone interested in disabling compression will be interested in doing so for many packages, not just one -- the use case would presumably be for building custom packages for personal use, where: - disk space is usually not an issue - bandwidth is unaffected since it is never traveling over the network - the cpu cycles and wait time for compression are thus not worth it
And in this case, it is equally true that you never want compression, whether you only intend to build one package ever, or not.
With the proposed patch, the semantics are simplified: Use --nocompress if you want no compression, versus remembering to use PKGEXT and what value to set it too.
The semantics become more complicated, because there are now three places to disable compression rather than two, and one of those places *only* disables compresion, while the other two are also useful to choose a compression type.
IMHO the current semantics are clearer, because the two places that it can be set are both defined as "choose a compression type, including 'no compression'"
The patch pulls this logic inside makepkg and adds it to the documentation (manpage, bash-completion, and --help). I'd say there is some definite value in the few extra lines this adds.
Anyway, thanks for your quick response! - Jouke
I don't think the argument should be about the number of lines it adds. Useful functionality should not be rejected for size issues except in extreme cases, and makepkg can definitely afford 284 bytes.
The issue I see is the increased surface this adds, the fact that the --help text becomes longer (it already has enough options that even the short help text does not completely fit on my screen), the minor cognitive burden of deducing which of several ways to specify a thing will take precedence if all of them are being used.
I'm not saying this is a major blocker, but it is definitely a consideration of some sort, and I don't currently believe there is a compelling argument that adding this syntactic sugar for an existing feature is sufficiently useful to justify yet another option.
...
Implementation-wise, if I was passing a command-line option I would expect it to work always, no matter what, with absolutely no exceptions. For example, if I pass --nocheck, I expect that to override makepkg.conf's BUILDENV setting, and in fact, makepkg has a separate state variable to determine whether it is explicitly overridden on the command line ($RUN_CHECK) or set via makepkg.conf (the check_buildenv() function):
if [[ $RUN_CHECK = 'y' ]] || { ! check_buildenv "check" "n" && [[ $RUN_CHECK != "n" ]]; }
Where this matters is for PKGBUILDs that have (unwisely) set this in the PKGBUILD itself. No matter how odd it is to do so, it should still be graded with the priority of a makepkg.conf setting, and not override an explicit command line option. This assumption holds true for --check/--nocheck, and does not hold true for your suggested --nocompress.
It also matters if someone sets an environment override, e.g.
makepkg CC=clang
makepkg has little-known behavior modeled after `make` in this regard. Your suggested implementation relies on the fact that makepkg performs option parsing before sourcing makepkg.conf, and that it backs up and restores the PKGEXT variable from the environment in order to preserve it. This results in the --nocompress option acting identical to setting the environment variable. But it is worth less than `extra_environment`. While I do not "expect" people to use the very confusing command line invocation:
makepkg --nocompress PKGEXT=.pkg.tar.xz
I would prefer that if we were to do this, we be consistent in how we handle it.
-- Eli Schwartz
Wow, thanks for this detailed response! This helps a lot with my understanding.
No problem! :) Have I convinced you that this is not needed, or do you still feel it has use and wish to continue to make the case for it or something similar (incorporating my implementation notes)? -- Eli Schwartz Bug Wrangler and Trusted User
On Sun, May 19, 2019 at 9:31 PM Eli Schwartz <eschwartz@archlinux.org> wrote:
On 5/19/19 3:20 PM, Jouke Witteveen wrote:
On Sun, May 19, 2019 at 5:01 AM Eli Schwartz <eschwartz@archlinux.org> wrote:
On 5/18/19 8:01 AM, Jouke Witteveen wrote:
On Sat, May 18, 2019 at 1:54 PM Allan McRae <allan@archlinux.org> wrote:
On 18/5/19 9:34 pm, Jouke Witteveen wrote:
Compression is a waste of time when building a package for local installation. It could already be suppressed easily, but not yet via an argument to makepkg.
As it could already be suppressed easily (makepkg.conf and with an environmental variable), we don't need an option.
makepkg.conf is of course unsuitable for one-off package building without compression. The environmental variable has different ergonomics and discoverability.
I agree with Allan that this is unnecessary.
My assumption is that anyone interested in disabling compression will be interested in doing so for many packages, not just one -- the use case would presumably be for building custom packages for personal use, where: - disk space is usually not an issue - bandwidth is unaffected since it is never traveling over the network - the cpu cycles and wait time for compression are thus not worth it
And in this case, it is equally true that you never want compression, whether you only intend to build one package ever, or not.
With the proposed patch, the semantics are simplified: Use --nocompress if you want no compression, versus remembering to use PKGEXT and what value to set it too.
The semantics become more complicated, because there are now three places to disable compression rather than two, and one of those places *only* disables compresion, while the other two are also useful to choose a compression type.
IMHO the current semantics are clearer, because the two places that it can be set are both defined as "choose a compression type, including 'no compression'"
The patch pulls this logic inside makepkg and adds it to the documentation (manpage, bash-completion, and --help). I'd say there is some definite value in the few extra lines this adds.
Anyway, thanks for your quick response! - Jouke
I don't think the argument should be about the number of lines it adds. Useful functionality should not be rejected for size issues except in extreme cases, and makepkg can definitely afford 284 bytes.
The issue I see is the increased surface this adds, the fact that the --help text becomes longer (it already has enough options that even the short help text does not completely fit on my screen), the minor cognitive burden of deducing which of several ways to specify a thing will take precedence if all of them are being used.
I'm not saying this is a major blocker, but it is definitely a consideration of some sort, and I don't currently believe there is a compelling argument that adding this syntactic sugar for an existing feature is sufficiently useful to justify yet another option.
...
Implementation-wise, if I was passing a command-line option I would expect it to work always, no matter what, with absolutely no exceptions. For example, if I pass --nocheck, I expect that to override makepkg.conf's BUILDENV setting, and in fact, makepkg has a separate state variable to determine whether it is explicitly overridden on the command line ($RUN_CHECK) or set via makepkg.conf (the check_buildenv() function):
if [[ $RUN_CHECK = 'y' ]] || { ! check_buildenv "check" "n" && [[ $RUN_CHECK != "n" ]]; }
Where this matters is for PKGBUILDs that have (unwisely) set this in the PKGBUILD itself. No matter how odd it is to do so, it should still be graded with the priority of a makepkg.conf setting, and not override an explicit command line option. This assumption holds true for --check/--nocheck, and does not hold true for your suggested --nocompress.
It also matters if someone sets an environment override, e.g.
makepkg CC=clang
makepkg has little-known behavior modeled after `make` in this regard. Your suggested implementation relies on the fact that makepkg performs option parsing before sourcing makepkg.conf, and that it backs up and restores the PKGEXT variable from the environment in order to preserve it. This results in the --nocompress option acting identical to setting the environment variable. But it is worth less than `extra_environment`. While I do not "expect" people to use the very confusing command line invocation:
makepkg --nocompress PKGEXT=.pkg.tar.xz
I would prefer that if we were to do this, we be consistent in how we handle it.
-- Eli Schwartz
Wow, thanks for this detailed response! This helps a lot with my understanding.
No problem! :)
Have I convinced you that this is not needed, or do you still feel it has use and wish to continue to make the case for it or something similar (incorporating my implementation notes)?
I am convinced :-). However, I do now think that it would maybe have been good to make PKGEXT=.pkg.tar the default in makepkg.conf, since local installation of AUR packages is probably the most common usecase of makepkg. Changing it now makes no sense as it will probably be too disruptive. The comment ("Do not modify unless [etc.]") could be improved to something more helpful, though. Regards, - Jouke
On 5/19/19 3:52 PM, Jouke Witteveen wrote:
On Sun, May 19, 2019 at 9:31 PM Eli Schwartz <eschwartz@archlinux.org> wrote:
On 5/19/19 3:20 PM, Jouke Witteveen wrote:
On Sun, May 19, 2019 at 5:01 AM Eli Schwartz <eschwartz@archlinux.org> wrote:
On 5/18/19 8:01 AM, Jouke Witteveen wrote:
On Sat, May 18, 2019 at 1:54 PM Allan McRae <allan@archlinux.org> wrote:
On 18/5/19 9:34 pm, Jouke Witteveen wrote: > Compression is a waste of time when building a package for local > installation. It could already be suppressed easily, but not yet > via an argument to makepkg.
As it could already be suppressed easily (makepkg.conf and with an environmental variable), we don't need an option.
makepkg.conf is of course unsuitable for one-off package building without compression. The environmental variable has different ergonomics and discoverability.
I agree with Allan that this is unnecessary.
My assumption is that anyone interested in disabling compression will be interested in doing so for many packages, not just one -- the use case would presumably be for building custom packages for personal use, where: - disk space is usually not an issue - bandwidth is unaffected since it is never traveling over the network - the cpu cycles and wait time for compression are thus not worth it
And in this case, it is equally true that you never want compression, whether you only intend to build one package ever, or not.
With the proposed patch, the semantics are simplified: Use --nocompress if you want no compression, versus remembering to use PKGEXT and what value to set it too.
The semantics become more complicated, because there are now three places to disable compression rather than two, and one of those places *only* disables compresion, while the other two are also useful to choose a compression type.
IMHO the current semantics are clearer, because the two places that it can be set are both defined as "choose a compression type, including 'no compression'"
The patch pulls this logic inside makepkg and adds it to the documentation (manpage, bash-completion, and --help). I'd say there is some definite value in the few extra lines this adds.
Anyway, thanks for your quick response! - Jouke
I don't think the argument should be about the number of lines it adds. Useful functionality should not be rejected for size issues except in extreme cases, and makepkg can definitely afford 284 bytes.
The issue I see is the increased surface this adds, the fact that the --help text becomes longer (it already has enough options that even the short help text does not completely fit on my screen), the minor cognitive burden of deducing which of several ways to specify a thing will take precedence if all of them are being used.
I'm not saying this is a major blocker, but it is definitely a consideration of some sort, and I don't currently believe there is a compelling argument that adding this syntactic sugar for an existing feature is sufficiently useful to justify yet another option.
...
Implementation-wise, if I was passing a command-line option I would expect it to work always, no matter what, with absolutely no exceptions. For example, if I pass --nocheck, I expect that to override makepkg.conf's BUILDENV setting, and in fact, makepkg has a separate state variable to determine whether it is explicitly overridden on the command line ($RUN_CHECK) or set via makepkg.conf (the check_buildenv() function):
if [[ $RUN_CHECK = 'y' ]] || { ! check_buildenv "check" "n" && [[ $RUN_CHECK != "n" ]]; }
Where this matters is for PKGBUILDs that have (unwisely) set this in the PKGBUILD itself. No matter how odd it is to do so, it should still be graded with the priority of a makepkg.conf setting, and not override an explicit command line option. This assumption holds true for --check/--nocheck, and does not hold true for your suggested --nocompress.
It also matters if someone sets an environment override, e.g.
makepkg CC=clang
makepkg has little-known behavior modeled after `make` in this regard. Your suggested implementation relies on the fact that makepkg performs option parsing before sourcing makepkg.conf, and that it backs up and restores the PKGEXT variable from the environment in order to preserve it. This results in the --nocompress option acting identical to setting the environment variable. But it is worth less than `extra_environment`. While I do not "expect" people to use the very confusing command line invocation:
makepkg --nocompress PKGEXT=.pkg.tar.xz
I would prefer that if we were to do this, we be consistent in how we handle it.
-- Eli Schwartz
Wow, thanks for this detailed response! This helps a lot with my understanding.
No problem! :)
Have I convinced you that this is not needed, or do you still feel it has use and wish to continue to make the case for it or something similar (incorporating my implementation notes)?
I am convinced :-). However, I do now think that it would maybe have been good to make PKGEXT=.pkg.tar the default in makepkg.conf, since local installation of AUR packages is probably the most common usecase of makepkg.
Changing it now makes no sense as it will probably be too disruptive. The comment ("Do not modify unless [etc.]") could be improved to something more helpful, though.
That is a very interesting point. Would you like to submit a patch modifying the manpage to suggest using .pkg.tar "if you want to disable compression"? -- Eli Schwartz Bug Wrangler and Trusted User
On Sun, May 19, 2019 at 10:01 PM Eli Schwartz <eschwartz@archlinux.org> wrote:
On 5/19/19 3:52 PM, Jouke Witteveen wrote:
However, I do now think that it would maybe have been good to make PKGEXT=.pkg.tar the default in makepkg.conf, since local installation of AUR packages is probably the most common usecase of makepkg.
Changing it now makes no sense as it will probably be too disruptive. The comment ("Do not modify unless [etc.]") could be improved to something more helpful, though.
That is a very interesting point. Would you like to submit a patch modifying the manpage to suggest using .pkg.tar "if you want to disable compression"?
Sure, but it is not clear to me what it should say exactly. Currently it says: ---- PKGEXT=".pkg.tar.gz", SRCEXT=".src.tar.gz" Sets the compression used when making compiled or source packages. Valid suffixes are .tar, .tar.gz, .tar.bz2, .tar.xz, .tar.lzo, .tar.lrz, and .tar.Z. Do not touch these unless you know what you are doing. ---- The first line is likely wrong, since it suggests .gz may be the default compression. This was not even the case when the line was added, nine years ago [1]! Then there is the last sentence. It is a bit weird to end this paragraph with "Use .tar to disable compression. Do not touch these unless you know what you are doing." Perhaps something like "Use .tar if you want to disable compression. Do not set these to a compression method other than the default unless you know what you are doing." is better. On the other hand, maybe the whole "...unless you know what you are doing." is a bit too strong anyway, and can simply be dropped. I think it is best to mirror whatever the manpage is going to say in /etc/makepkg.conf. Sorry to make this a bigger fuzz than it deserves. Feel free to simply change the text as you see fit if you think that is easier than waiting for a patch from me. Regards, - Jouke [1] https://bugs.archlinux.org/task/21302
On 5/21/19 4:30 AM, Jouke Witteveen wrote:
On Sun, May 19, 2019 at 10:01 PM Eli Schwartz <eschwartz@archlinux.org> wrote:
On 5/19/19 3:52 PM, Jouke Witteveen wrote:
However, I do now think that it would maybe have been good to make PKGEXT=.pkg.tar the default in makepkg.conf, since local installation of AUR packages is probably the most common usecase of makepkg.
Changing it now makes no sense as it will probably be too disruptive. The comment ("Do not modify unless [etc.]") could be improved to something more helpful, though.
That is a very interesting point. Would you like to submit a patch modifying the manpage to suggest using .pkg.tar "if you want to disable compression"?
Sure, but it is not clear to me what it should say exactly.
Currently it says:
---- PKGEXT=".pkg.tar.gz", SRCEXT=".src.tar.gz" Sets the compression used when making compiled or source packages. Valid suffixes are .tar, .tar.gz, .tar.bz2, .tar.xz, .tar.lzo, .tar.lrz, and .tar.Z. Do not touch these unless you know what you are doing. ----
The first line is likely wrong, since it suggests .gz may be the default compression. This was not even the case when the line was added, nine years ago [1]! Then there is the last sentence. It is a bit weird to end this paragraph with "Use .tar to disable compression. Do not touch these unless you know what you are doing." Perhaps something like "Use .tar if you want to disable compression. Do not set these to a compression method other than the default unless you know what you are doing." is better. On the other hand, maybe the whole "...unless you know what you are doing." is a bit too strong anyway, and can simply be dropped.
I think it is best to mirror whatever the manpage is going to say in /etc/makepkg.conf.
Sorry to make this a bigger fuzz than it deserves. Feel free to simply change the text as you see fit if you think that is easier than waiting for a patch from me.
Regards, - Jouke
Actually, the default pacman/makepkg configuration is indeed gz, at least in the sense that that is what etc/makepkg.conf.in will be configured with unless you define your own: ./configure --with-pkg-ext --with-src-ext Arch Linux does not ship with the stock pacman.conf and makepkg.conf, though. We set distribution defaults independent of the distro-agnostic pacman.git sources; these distribution defaults include the use of xz over gzip for compression. I'm not sure what would make an appropriate default, since unlike many other makepkg.conf settings the fallback when unspecified is to carry on as if '' is a plausible answer when it isn't, and it *should* raise a fatal error I guess. I'll write a lint check for that... Perhaps it would make sense to have the manpage depend on how --with-pkg-ext --with-src-ext were used. Although Arch Linux would still then be calling out gz. -- Eli Schwartz Bug Wrangler and Trusted User
On 5/21/19 5:42 PM, Eli Schwartz wrote:
On 5/21/19 4:30 AM, Jouke Witteveen wrote:
On Sun, May 19, 2019 at 10:01 PM Eli Schwartz <eschwartz@archlinux.org> wrote:
On 5/19/19 3:52 PM, Jouke Witteveen wrote:
However, I do now think that it would maybe have been good to make PKGEXT=.pkg.tar the default in makepkg.conf, since local installation of AUR packages is probably the most common usecase of makepkg.
Changing it now makes no sense as it will probably be too disruptive. The comment ("Do not modify unless [etc.]") could be improved to something more helpful, though.
That is a very interesting point. Would you like to submit a patch modifying the manpage to suggest using .pkg.tar "if you want to disable compression"?
Sure, but it is not clear to me what it should say exactly.
Currently it says:
---- PKGEXT=".pkg.tar.gz", SRCEXT=".src.tar.gz" Sets the compression used when making compiled or source packages. Valid suffixes are .tar, .tar.gz, .tar.bz2, .tar.xz, .tar.lzo, .tar.lrz, and .tar.Z. Do not touch these unless you know what you are doing. ----
The first line is likely wrong, since it suggests .gz may be the default compression. This was not even the case when the line was added, nine years ago [1]! Then there is the last sentence. It is a bit weird to end this paragraph with "Use .tar to disable compression. Do not touch these unless you know what you are doing." Perhaps something like "Use .tar if you want to disable compression. Do not set these to a compression method other than the default unless you know what you are doing." is better. On the other hand, maybe the whole "...unless you know what you are doing." is a bit too strong anyway, and can simply be dropped.
I think it is best to mirror whatever the manpage is going to say in /etc/makepkg.conf.
Sorry to make this a bigger fuzz than it deserves. Feel free to simply change the text as you see fit if you think that is easier than waiting for a patch from me.
Regards, - Jouke
Actually, the default pacman/makepkg configuration is indeed gz, at least in the sense that that is what etc/makepkg.conf.in will be configured with unless you define your own: ./configure --with-pkg-ext --with-src-ext
Arch Linux does not ship with the stock pacman.conf and makepkg.conf, though. We set distribution defaults independent of the distro-agnostic pacman.git sources; these distribution defaults include the use of xz over gzip for compression.
I'm not sure what would make an appropriate default, since unlike many other makepkg.conf settings the fallback when unspecified is to carry on as if '' is a plausible answer when it isn't, and it *should* raise a fatal error I guess. I'll write a lint check for that...
https://lists.archlinux.org/pipermail/pacman-dev/2019-May/023404.html for the lint check
Perhaps it would make sense to have the manpage depend on how --with-pkg-ext --with-src-ext were used. Although Arch Linux would still then be calling out gz.
Done and with a transition from scariness to "this is how you disable compression": https://lists.archlinux.org/pipermail/pacman-dev/2019-May/023405.html -- Eli Schwartz Bug Wrangler and Trusted User
On Wed, May 22, 2019 at 12:45 AM Eli Schwartz <eschwartz@archlinux.org> wrote:
On 5/21/19 5:42 PM, Eli Schwartz wrote:
On 5/21/19 4:30 AM, Jouke Witteveen wrote:
On Sun, May 19, 2019 at 10:01 PM Eli Schwartz <eschwartz@archlinux.org> wrote:
On 5/19/19 3:52 PM, Jouke Witteveen wrote:
However, I do now think that it would maybe have been good to make PKGEXT=.pkg.tar the default in makepkg.conf, since local installation of AUR packages is probably the most common usecase of makepkg.
Changing it now makes no sense as it will probably be too disruptive. The comment ("Do not modify unless [etc.]") could be improved to something more helpful, though.
That is a very interesting point. Would you like to submit a patch modifying the manpage to suggest using .pkg.tar "if you want to disable compression"?
Sure, but it is not clear to me what it should say exactly.
Currently it says:
---- PKGEXT=".pkg.tar.gz", SRCEXT=".src.tar.gz" Sets the compression used when making compiled or source packages. Valid suffixes are .tar, .tar.gz, .tar.bz2, .tar.xz, .tar.lzo, .tar.lrz, and .tar.Z. Do not touch these unless you know what you are doing. ----
The first line is likely wrong, since it suggests .gz may be the default compression. This was not even the case when the line was added, nine years ago [1]! Then there is the last sentence. It is a bit weird to end this paragraph with "Use .tar to disable compression. Do not touch these unless you know what you are doing." Perhaps something like "Use .tar if you want to disable compression. Do not set these to a compression method other than the default unless you know what you are doing." is better. On the other hand, maybe the whole "...unless you know what you are doing." is a bit too strong anyway, and can simply be dropped.
I think it is best to mirror whatever the manpage is going to say in /etc/makepkg.conf.
Sorry to make this a bigger fuzz than it deserves. Feel free to simply change the text as you see fit if you think that is easier than waiting for a patch from me.
Regards, - Jouke
Actually, the default pacman/makepkg configuration is indeed gz, at least in the sense that that is what etc/makepkg.conf.in will be configured with unless you define your own: ./configure --with-pkg-ext --with-src-ext
Arch Linux does not ship with the stock pacman.conf and makepkg.conf, though. We set distribution defaults independent of the distro-agnostic pacman.git sources; these distribution defaults include the use of xz over gzip for compression.
I'm not sure what would make an appropriate default, since unlike many other makepkg.conf settings the fallback when unspecified is to carry on as if '' is a plausible answer when it isn't, and it *should* raise a fatal error I guess. I'll write a lint check for that...
https://lists.archlinux.org/pipermail/pacman-dev/2019-May/023404.html for the lint check
Thanks! Pretty funny how quickly this escalated :-).
Perhaps it would make sense to have the manpage depend on how --with-pkg-ext --with-src-ext were used. Although Arch Linux would still then be calling out gz.
Done and with a transition from scariness to "this is how you disable compression": https://lists.archlinux.org/pipermail/pacman-dev/2019-May/023405.html
Shouldn't the WARNING in etc/makepkg.conf.in be updated too? Thanks again, - Jouke
On 5/22/19 3:37 AM, Jouke Witteveen wrote:
On Wed, May 22, 2019 at 12:45 AM Eli Schwartz <eschwartz@archlinux.org> wrote:
Done and with a transition from scariness to "this is how you disable compression": https://lists.archlinux.org/pipermail/pacman-dev/2019-May/023405.html
Shouldn't the WARNING in etc/makepkg.conf.in be updated too?
Thanks, fixed! -- Eli Schwartz Bug Wrangler and Trusted User
participants (3)
-
Allan McRae
-
Eli Schwartz
-
Jouke Witteveen