[rb-general] buildinfo filename convention

Chris Lamb lamby at debian.org
Fri Aug 10 10:10:36 CEST 2018

Hi Arnout,

> ... where the '_${STRING}' part is allowed to disambiguate different
> uploads, but is optional.
> This way 'foo_0.1.2_all.buildinfo' and
> 'foo_0.1.2_all_yinka-1533833907.buildinfo' would both be acceptable
> filenames.

Interesting proposal. I wonder, did you consider:



 * Is much simpler and intuitively obvious what is going on.

 * Retains the highly-desirable property that basename contains solely
   meaningful data and the suffix is simply an implementation detail
   given you are storing them in a UNIX filesystem in this case.
   After all, other storage systems or mechanisms for .buildinfo files
   may not share this limitation. In addition, at least to me, is much
   easier to parse "by eye" when it can split the filename on the ".".
 * The arbitrary string in your proposal does not require any
   definition; I'm sure $project might use date +%s and others might
   use something else which is a little messy IMHO.
 * Is used elsewhere in Debian so is somewhat of a de facto convention.

 * Does not require an "ad-hoc" optional part, which isn't that
   aesthetically pleasing from a specification point of view.

Naturally, the downside is that it does not match the "*.buildinfo"
glob, but I think this is an acceptable trade-off given the above. :)

> Any thoughts? If no-one has objections I'll update the wiki and the
> text at https://buildinfo.debian.net/ to consistently recommend this
> convention.

Ooh, I 100% appreciate getting your hands dirty! I guess I'd just be
very slighty wary of updating the wiki without, for example, also
ensuring core tools such as dpkg have wishlist bugs filed against them
(if needed, of course...). :)


     : :'  :     Chris Lamb
     `. `'`      lamby at debian.org / chris-lamb.co.uk

More information about the rb-general mailing list