[pacman-dev] Order of option parsing and sourcing makepkg.conf
Hi, With the commit which enables us to specify the makepkg config file on the command-line (http://projects.archlinux.org/?p=pacman.git;a=commitdiff;h=4b183bf9), the sourcing of the config file gets moved after the parsing of the options. This creates problems with the --help flag as it needs to know what BUILDSCRIPT is defined as. It also causes problems when specifying a different BUILDSCRIPT with -p as this gets set during option parsing then gets overwritten with the makepkg config file gets sourced. I don't see a nice fix for this. Sourcing the conf file before option parsing and then again after if it is changed seems not good to me. So can we back that patch out at least temporarily. Note that this does not effect maint so the 3.2.2 release will be bug free as usual. Allan
Allan McRae wrote:
Hi,
With the commit which enables us to specify the makepkg config file on the command-line (http://projects.archlinux.org/?p=pacman.git;a=commitdiff;h=4b183bf9), the sourcing of the config file gets moved after the parsing of the options. This creates problems with the --help flag as it needs to know what BUILDSCRIPT is defined as. It also causes problems when specifying a different BUILDSCRIPT with -p as this gets set during option parsing then gets overwritten with the makepkg config file gets sourced.
I don't see a nice fix for this. Sourcing the conf file before option parsing and then again after if it is changed seems not good to me. So can we back that patch out at least temporarily.
Note that this does not effect maint so the 3.2.2 release will be bug free as usual.
Here is a link to the original discussion of this patch: http://archlinux.org/pipermail/pacman-dev/2008-August/007321.html Allan
On Tue, Dec 9, 2008 at 6:55 AM, Allan McRae <allan@archlinux.org> wrote:
Allan McRae wrote:
Hi,
With the commit which enables us to specify the makepkg config file on the command-line (http://projects.archlinux.org/?p=pacman.git;a=commitdiff;h=4b183bf9), the sourcing of the config file gets moved after the parsing of the options. This creates problems with the --help flag as it needs to know what BUILDSCRIPT is defined as. It also causes problems when specifying a different BUILDSCRIPT with -p as this gets set during option parsing then gets overwritten with the makepkg config file gets sourced.
I don't see a nice fix for this. Sourcing the conf file before option parsing and then again after if it is changed seems not good to me. So can we back that patch out at least temporarily.
Note that this does not effect maint so the 3.2.2 release will be bug free as usual.
Here is a link to the original discussion of this patch: http://archlinux.org/pipermail/pacman-dev/2008-August/007321.html
Maybe we should reconsider moving BUILDSCRIPT out of makepkg and into makepkg.conf? This was commit 9c9e18ef32c0cf3, it feels like eons ago. But let's be honest- how often is someone going to change the name of PKGBUILD or should even care about it? If we at least initially define it in makepkg, and allow for overrides in makepkg.conf, it probably isn't the end of the world. -Dan
Dan McGee wrote:
On Tue, Dec 9, 2008 at 6:55 AM, Allan McRae <allan@archlinux.org> wrote:
Allan McRae wrote:
Hi,
With the commit which enables us to specify the makepkg config file on the command-line (http://projects.archlinux.org/?p=pacman.git;a=commitdiff;h=4b183bf9), the sourcing of the config file gets moved after the parsing of the options. This creates problems with the --help flag as it needs to know what BUILDSCRIPT is defined as. It also causes problems when specifying a different BUILDSCRIPT with -p as this gets set during option parsing then gets overwritten with the makepkg config file gets sourced.
I don't see a nice fix for this. Sourcing the conf file before option parsing and then again after if it is changed seems not good to me. So can we back that patch out at least temporarily.
Note that this does not effect maint so the 3.2.2 release will be bug free as usual.
Here is a link to the original discussion of this patch: http://archlinux.org/pipermail/pacman-dev/2008-August/007321.html
Maybe we should reconsider moving BUILDSCRIPT out of makepkg and into makepkg.conf? This was commit 9c9e18ef32c0cf3, it feels like eons ago. But let's be honest- how often is someone going to change the name of PKGBUILD or should even care about it? If we at least initially define it in makepkg, and allow for overrides in makepkg.conf, it probably isn't the end of the world.
Well, that would be the easy fix I didn't see... I have no objections to moving BUILDSCRIPT back into makepkg. I would be surprised if anyone ever changed it. And we provide the "-p" flag if someone wants to override it anyway. Allan
On Tue, Dec 9, 2008 at 8:55 AM, Allan McRae <allan@archlinux.org> wrote:
Dan McGee wrote:
On Tue, Dec 9, 2008 at 6:55 AM, Allan McRae <allan@archlinux.org> wrote:
Allan McRae wrote:
Hi,
With the commit which enables us to specify the makepkg config file on the command-line (http://projects.archlinux.org/?p=pacman.git;a=commitdiff;h=4b183bf9), the sourcing of the config file gets moved after the parsing of the options. This creates problems with the --help flag as it needs to know what BUILDSCRIPT is defined as. It also causes problems when specifying a different BUILDSCRIPT with -p as this gets set during option parsing then gets overwritten with the makepkg config file gets sourced.
I don't see a nice fix for this. Sourcing the conf file before option parsing and then again after if it is changed seems not good to me. So can we back that patch out at least temporarily.
Note that this does not effect maint so the 3.2.2 release will be bug free as usual.
Here is a link to the original discussion of this patch: http://archlinux.org/pipermail/pacman-dev/2008-August/007321.html
Maybe we should reconsider moving BUILDSCRIPT out of makepkg and into makepkg.conf? This was commit 9c9e18ef32c0cf3, it feels like eons ago. But let's be honest- how often is someone going to change the name of PKGBUILD or should even care about it? If we at least initially define it in makepkg, and allow for overrides in makepkg.conf, it probably isn't the end of the world.
Well, that would be the easy fix I didn't see... I have no objections to moving BUILDSCRIPT back into makepkg. I would be surprised if anyone ever changed it. And we provide the "-p" flag if someone wants to override it anyway.
Just an FYI for if you do this. The db-scripts uses $BUILDSCRIPT, so I will need to define it myself before you upgrade pacman on gerolde.
On Tue, Dec 9, 2008 at 10:08 AM, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
On Tue, Dec 9, 2008 at 8:55 AM, Allan McRae <allan@archlinux.org> wrote:
Dan McGee wrote:
On Tue, Dec 9, 2008 at 6:55 AM, Allan McRae <allan@archlinux.org> wrote:
Allan McRae wrote:
Hi,
With the commit which enables us to specify the makepkg config file on the command-line (http://projects.archlinux.org/?p=pacman.git;a=commitdiff;h=4b183bf9), the sourcing of the config file gets moved after the parsing of the options. This creates problems with the --help flag as it needs to know what BUILDSCRIPT is defined as. It also causes problems when specifying a different BUILDSCRIPT with -p as this gets set during option parsing then gets overwritten with the makepkg config file gets sourced.
I don't see a nice fix for this. Sourcing the conf file before option parsing and then again after if it is changed seems not good to me. So can we back that patch out at least temporarily.
Note that this does not effect maint so the 3.2.2 release will be bug free as usual.
Here is a link to the original discussion of this patch: http://archlinux.org/pipermail/pacman-dev/2008-August/007321.html
Maybe we should reconsider moving BUILDSCRIPT out of makepkg and into makepkg.conf? This was commit 9c9e18ef32c0cf3, it feels like eons ago. But let's be honest- how often is someone going to change the name of PKGBUILD or should even care about it? If we at least initially define it in makepkg, and allow for overrides in makepkg.conf, it probably isn't the end of the world.
Well, that would be the easy fix I didn't see... I have no objections to moving BUILDSCRIPT back into makepkg. I would be surprised if anyone ever changed it. And we provide the "-p" flag if someone wants to override it anyway.
Just an FYI for if you do this. The db-scripts uses $BUILDSCRIPT, so I will need to define it myself before you upgrade pacman on gerolde.
As long as no one merges/deletes things from makepkg.conf you're fine. :) -Dan
Allan McRae wrote:
Dan McGee wrote:
On Tue, Dec 9, 2008 at 6:55 AM, Allan McRae <allan@archlinux.org> wrote:
Allan McRae wrote:
Hi,
With the commit which enables us to specify the makepkg config file on the command-line (http://projects.archlinux.org/?p=pacman.git;a=commitdiff;h=4b183bf9), the sourcing of the config file gets moved after the parsing of the options. This creates problems with the --help flag as it needs to know what BUILDSCRIPT is defined as. It also causes problems when specifying a different BUILDSCRIPT with -p as this gets set during option parsing then gets overwritten with the makepkg config file gets sourced.
I don't see a nice fix for this. Sourcing the conf file before option parsing and then again after if it is changed seems not good to me. So can we back that patch out at least temporarily.
Note that this does not effect maint so the 3.2.2 release will be bug free as usual.
Here is a link to the original discussion of this patch: http://archlinux.org/pipermail/pacman-dev/2008-August/007321.html
Maybe we should reconsider moving BUILDSCRIPT out of makepkg and into makepkg.conf? This was commit 9c9e18ef32c0cf3, it feels like eons ago. But let's be honest- how often is someone going to change the name of PKGBUILD or should even care about it? If we at least initially define it in makepkg, and allow for overrides in makepkg.conf, it probably isn't the end of the world.
Well, that would be the easy fix I didn't see... I have no objections to moving BUILDSCRIPT back into makepkg. I would be surprised if anyone ever changed it. And we provide the "-p" flag if someone wants to override it anyway.
I was going to fix this issue but I was wanting to know the reasoning behind allowing someone to set a different name for the BUILDSCRIPT. Was for if another distro using pacman wanted to call it something other the PKGBUILD? I.e. should I autoconf this rather than hard-coding it in makepkg? Allan
participants (3)
-
Aaron Griffin
-
Allan McRae
-
Dan McGee