Bug#918438: orig tarball components with uppercase letters
Hi!
On Sun, 2019-01-06 at 00:34:30 +0000, Ian Jackson wrote:
> Package: debian-policy
> Version: 3.9.8.0
> dpkg-source format `3.0 (quilt)' supports what it calls `additional
> orig tarballs', named
> <package>-<upstreamvsn>.orig-<component>.tar.<ext>
>
> The documentation in dpkg-source(1) says
> component can only contain alphanumeric characters and hyphens
This is actually part of the “2.0” format, which got inherited by the
“3.0 (quilt)” format, which is based on the former.
See commit 3748a23e47c1af76f291f3c4caa98eefc45ff508 for the initial
introduction and commit ff03345b7a8d9dd0950dc581c5263373b2a0b406 for
its further restriction.
> This allows the possibility of uppercase letters [1]. But of course
> distinguishing case of letters is troublesome for some computers.
> This specification makes it possible for two different source package
> component files to exist with names which differ only in the case of
> some of the letters - perhaps, even two files which are part of the
> very same package version and must necessarily exist side by side.
Right, and this diverges from the prevalent principle that source and
binary package name components in filenames are lower-cased.
> It seems obvious to me that any reliance on case here is undesirable.
But, pondering about this now, this opens the hypothetical problem of
versions which can have the same exact problem! And we could also have:
foo_1.0a_amd64.deb
foo_1.0A_amd64.deb
:/
So when I first read this proposal, I was initially in favor of it and
ready to implement it in dpkg-source. But given the above, I'm now not
so sure whether it make sense anymore TBH.
> (I erroneously mishandled this case in dgit, due to not reading the
> spec properly. This caused lossage to a Debian downstream. #916926.)
(See below, I'll clarify this.)
> I would like to arrange, somehow, that our tools and policies ensure
> that filename clashes cannot occur even on case-insensitive
> filesystems.
> I don't think we can solve this in dpkg. All it could is reject all
> uppercase letters. That is not backward compatible: we don't want to
> add to the situations where it is not possible to edit and rebuild an
> old source package.
If this is desirable, I don't see why it cannot be done at the dpkg
level TBH. The requirement here is that dpkg-source must preserve the
ability to pack and unpack these packages, but that does not
necessarily mean it needs to allow that by default.
I could see introducing both a warning on upper-case letter usage, and
force options to both pack and unpack such source packages. Then…
> Eventually, when everything is converted, the restriction could be
> made firm (MUST; lintian error) and that would get us into a situation
> where we can't accidentally mess this up in the future.
…later on those warnings could be turned into dpkg-source errors.
> [1] Technically the spec also allows the possibility of non-ASCII
> letters and numbes but I doubt anyone would read that that was
> intended and I am confident that dpkg-source would actually reject
> those.
Yes, in the dpkg context when it comes to names as part of namespaces
and interfaces these tend to be restricted to ASCII characters. I'll
make that explicit in the man page, thanks.
Regards,
Guillem
Reply to: