On Tue, 2016-02-02 at 16:34:40 +0100, Jérémy Bobbio wrote:
> We were discussions the restrictions on buildinfo identifiers:
>     fweb_1.62-12+b2_brahms-20120530T114812Z.buildinfo
>                     ^^^^^^^^^^^^^^^^^^^^^^^
>                           this part
> The proposal was “the string should consist only of alphanumeric
> characters and hyphens”. Guillem made the following comment while
> reviewing the patches for dpkg:
> Guillem Jover:
> > Can we just simply use the package name rules instead? It also avoids
> > potential problems with case and similar. (There's a
> > pkg_name_is_illegal function in Dpkg::Package already.)
> After reaching out to Ansgar with a patch for dak to implement the
> above, he replied:
> Ansgar Burchardt:
> > The allowed sets for package names and the suffix of buildinfo
> > filenames won't be the same even with that change.  However currently
> > the suffix of buildinfo filenames matches what is allowed for .changes
> > files.

Ah ok matching what is allowed in «.changes» with what is allowed in
«.buildinfo» makes sense. But…

> > I'm not sure why allowing capital letters used in the suffix of
> > buildinfo files should be an issue? After all we allow capital letters
> > for both version numbers (part of the filename) and in names of changes
> > files.

…are uppercase letters allowed for the third (arch) component in
.changes files? No architecture should be uppercase anyway.

I'd just like to avoid allowing things that then becomes very
difficult to ban after the fact.

> > (In the other direction not everything allowed as a package name can be
> > used as the suffix of .changes and .buildinfo files either.)

True, which would introduce more undesired things.

> Guillem, any further comments? Do you have any strong opposition to the
> initial proposal?

Actually after consideration, I don't think I have, more so if it
makes representing dates in an incorrect way (the ‘Z’).


Reproducible-builds mailing list

Reply via email to