[rb-general] buildinfo filename convention

[Arnout Engelen]

On Fri, Aug 10, 2018 at 10:10 AM, Chris Lamb <lamby at debian.org> wrote:
>>   ${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 ".".

Yes, different systems have different limitations: indeed
'foo_0.1.2_all.buildinfo.0' is neat on a local filesystem.

When using a generic directory sharing mechanism (e.g. git, dropbox, ...)
this mechanism is less nice, since you have to read the current contents
of the directory to determine what the 'next filename' should be. Locally
that's fine, but on the network that can lead to race conditions.
Not unsolvable, but inconvenient.

>  * 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.

Yes, you'd probably further standardize this per 'ecosystem'.

>  * 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. :)

I agree breaking '*.buildinfo' is not a big deal.

Perhaps we should document
${SOURCE}_${DEBIAN_VERSION}_${ARCHITECTURE}.buildinfo
as the 'main' convention, but avoid prescribing it too harshly.



Arnout