[rb-general] buildinfo filename convention
Chris Lamb
lamby at debian.org
Fri Aug 10 10:10:36 CEST 2018
Hi Arnout,
> ${SOURCE}_${DEBIAN_VERSION}_${ARCHITECTURE}_${STRING}.buildinfo
>
> ... 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:
foo_0.1.2_all.buildinfo
foo_0.1.2_all.buildinfo.0
foo_0.1.2_all.buildinfo.1
etc.
This:
* 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...). :)
Regards,
--
,''`.
: :' : Chris Lamb
`. `'` lamby at debian.org / chris-lamb.co.uk
`-
More information about the rb-general
mailing list