Re: Common configuration of Debianish build etc. tools

2019-09-11 Thread Marcin Kulisz
On 11 September 2019 20:24:07 BST, gregor herrmann  wrote:
>On Wed, 11 Sep 2019 16:22:18 +0100, Ian Jackson wrote:
>
>> One example is:
>>export-dir (gbp)
>>buildresult (pbuilder)
>>build-products-dir (dgit)
>>build-dir (sbuild)
>> 
>> So, it would be good for there to be a single way to configure these
>> things.  Every tool ought to look in this single place as well as its
>> own configuration.
>
>Ack.
>Using export-dir in gbp, I had to set build-products-dir for dgit
>recently, which felt a bit boring.

I went through exactly the same issue a few weeks back, so +1 from me to Ian 
proposal with Russ suggestion about xdg.

I'd like to add that one line or two, added into each tool man page about this 
config file option would also be nice.



Re: Common configuration of Debianish build etc. tools

2019-09-11 Thread Paul Wise
On Thu, Sep 12, 2019 at 3:24 AM gregor herrmann wrote:

> ~/.devscripts already exists (typically) which similar variables,
> maybe this could be re-used?

Using ~/.devscripts means running shell and passing variables out of
it, which is quite hard to get right. The devscripts config loading
module got it wrong until recently, is still a bit hacky really (but
there is a patch) and still needs migration of many of the scripts
from their own bad config loading implementations to the config
loading module. I think it would be best to avoid code (especially
shell) as configuration in favour of static configuration files with
dynamic overrides added via environment variables where needed.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise



Re: Common configuration of Debianish build etc. tools

2019-09-11 Thread gregor herrmann
On Wed, 11 Sep 2019 16:22:18 +0100, Ian Jackson wrote:

> One example is:
>export-dir (gbp)
>buildresult (pbuilder)
>build-products-dir (dgit)
>build-dir (sbuild)
> 
> So, it would be good for there to be a single way to configure these
> things.  Every tool ought to look in this single place as well as its
> own configuration.

Ack.
Using export-dir in gbp, I had to set build-products-dir for dgit
recently, which felt a bit boring.
 
> If this is a good idea then we need to agree on a filename and format.
> The format must be easy to parse in a variety of programming languages
> including, in particular, shell scripts.  Any suggestions ?

~/.devscripts already exists (typically) which similar variables,
maybe this could be re-used?
 
Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   


signature.asc
Description: Digital Signature


Re: Common configuration of Debianish build etc. tools

2019-09-11 Thread Johannes Schauer
Quoting Russ Allbery (2019-09-11 18:15:45)
> I think this is a good idea.

+1

Patches to sbuild welcome!

I wonder which configuration should take precedence in case a setting is
specified in the common configuration file as well as in another way that the
program understands -- probably the latter should overrule the former?

Thanks!

cheers, josch


signature.asc
Description: signature


Re: Common configuration of Debianish build etc. tools

2019-09-11 Thread Russ Allbery
I think this is a good idea.

Ian Jackson  writes:

> It shouldn't just be an environment variable because that clutters the
> environment unnecessarily.  I think it should probably be a config
> file in ~, overrideable with an environment variable.  (Or perhaps the
> config filename could be overrideable with an environment variable.)

The currently popular bikeshed color (with widespread support in multiple
languages) is to use the XDG Base Directory Specification, which defaults
to looking in ~/.config and honors XDG_CONFIG_HOME as an environment
variable to move those files elsewhere.  I personally much prefer this
because it reduces clutter in $HOME and also moves config files into a
separate directory (which one can then easily keep in version control)
from other crap that programs want to write in the home directory but that
I don't particularly care about, like cache files, .lesshst, .history,
.viminfo, and so forth.

All of the logic is implemented for you in Perl in File::BaseDir, in Rust
in the xdg crate, in Python in python3-xdg, and so forth.

-- 
Russ Allbery (r...@debian.org)   



Common configuration of Debianish build etc. tools

2019-09-11 Thread Ian Jackson
Hi.

Our rich ecosystem of packaging tools has a large number of
configuration options.  In some cases, different tools need to have
the same option set in the same way.  But we have no common place to
put this information and often not even common terminology.

One example is:
   export-dir (gbp)
   buildresult (pbuilder)
   build-products-dir (dgit)
   build-dir (sbuild)

When one of these tools invokes others, it can sometimes pass down an
option, but unless we are to have a kind of universal wrapper program,
this is not always possible.  (And we have too many wrappers already.)

So, it would be good for there to be a single way to configure these
things.  Every tool ought to look in this single place as well as its
own configuration.

It shouldn't just be an environment variable because that clutters the
environment unnecessarily.  I think it should probably be a config
file in ~, overrideable with an environment variable.  (Or perhaps the
config filename could be overrideable with an environment variable.)

What do people think ?

If this is a good idea then we need to agree on a filename and format.
The format must be easy to parse in a variety of programming languages
including, in particular, shell scripts.  Any suggestions ?

Also there should be a registry document in some package somewhere,
which declares the format and lists the known config keys and their
semantics.

Thanks,
Ian.

PS Note that we are talking here about settings which relate to
personal preferences, or machine-local setup.  Not ones which are
properties of the package and which must therefore be done the same
way by all of a package's maintainers - that latter information must
be elsewhere (in the source package, recorded in salsa, or something.)

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.