On Thu, Aug 7, 2008 at 7:43 AM, Xavier <[EMAIL PROTECTED]> wrote:
>
> On Thu, Aug 7, 2008 at 2:17 PM, hoar heor <[EMAIL PROTECTED]> 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 _______________________________________________ pacman-dev mailing list [email protected] http://archlinux.org/mailman/listinfo/pacman-dev
