[pacman-dev] added --config option to makepkg

[Dan McGee]

On Thu, Aug 7, 2008 at 7:43 AM, Xavier <shiningxc at gmail.com> wrote:
>
> On Thu, Aug 7, 2008 at 2:17 PM, hoar heor <archye at pycut.com.ar> wrote:
> >
> > I don't really understand what you mean with gettext, as far as I know
> > it's using it(although I maybe had skipped something)
> >
> <snip>
> > I know i't's a bit complicated, but otherwise it would source the file
> > several times if there are more arguments(maybe there's some other way
> > simpler to do it that I haven't noticed, anyway I'm still looking at
> > the source to simplify it)
>
> I meant getopts of course...
>
> > well, it's not only intended to be used with "safe" makepkg, look it
> > this way, someone has -arch and -mute changed to his platform so the
> > packages are optimized, the problem is that they won't work on other
> > processor, if that person builds the package for a repo he will have
> > to change makepkg.conf in this way he could do makepkg
> > --config=release and it would source makepkg.release(witch obviously
> > must have had created earlier), or maybe a specific makepkg for one
> > package makepkg --config=python wich would use makepkg.python
> >
>
> Obviously, the symlinks solution is not limited to two configs either.
>
> And the env var way can be modified as well to support any configs.
> Just use MAKEPKGCONF="configname"
> Then makepkg.conf can be just one line : source
> /etc/${MAKEPKGCONF:-makepkg.conf.default}

Let's take a step back here.

Problem: it is not easy to build packages with different makepkg.conf files.
Seemingly simple solution: add a command-line parameter to specify a
different config file.

The original solution proposed was too restrictive IMO, we do crazy
things with adding extensions to a hardcoded /etc/makpkg.* location
and who knows what. We should at least give the option of picking a
config file from any location.

Besides that, we may need to revisit the fact that both
/etc/makepkg.conf and ~/.makepkg.conf are currently read; is this
really not sufficient for most needs? To be honest, makepkg is so
rarely run as root and almost always run as a user that it makes more
sense to only read the homedir file if we weren't trying to be
backward compatible. But now I'm off on a tangent. :)

What was wrong with moving the config file reading after the getopt
options parsing? Did I miss something, or can't we handle a --config
option in this same fashion?

I agree we might have a valuable feature request here; I just think
the first patch took the wrong approach and was too specific anyway.

-Dan