Why packages tarballs have to be in lowercase ?

[Emmanuel Charpentier]

The Developer's guide states the ported packages' tarballs have to be in lower case :
"The build scripts and associated files are in a subdirectory SAGE_ROOT/build/pkgs/package, where you replace package with a lower-case version of the upstream project name."

I am wondering what parts of the build system needs this restriction, that seems to be unenforceable on Macs (see trac#18229 for discussion, and examples in trac#16759 and trac#18341), and possibly on Windows, if and when we have a Windows native version. The sage-fix-pkg-checksums script, which creates packages checksums, is known not to treat mixedCased tarballs. So, two questions :

1. What other parts of the build system are broken by mixedCased tarballs ?
2. Is this restriction really necessary ?

HTH,
--
Emmanuel Charpentier

[Jeroen Demeyer]

On 2015-04-30 08:57, Emmanuel Charpentier wrote:
> The Developer's guide
> <http://www.sagemath.org/doc/developer/packaging.html#directory-structure>
> states the ported packages' tarballs have to be in *lower case* :

> "The build scripts and associated files are in a subdirectory
> SAGE_ROOT/build/pkgs/package, where you replace package with a
> lower-case version of the upstream project name."

That's about the directory in build/pkgs, not the tarball name.

> 1. What other parts of the build system are broken by mixedCased tarballs ?
No part of the build system is broken by mixedCased tarball.

> 2. Is this restriction really necessary ?
There is no such restriction, see answer 1.

[Francois Bissey]

I remember you saying that in the R-3.2.0 ticket. That being said,
the tarballs for Pillow and Sphinx have a capital but their hosting folder
in build/pkgs doesn’t. It feels like a case where we should do a bit of tidy
up.

Francois

[leif]

Not exactly.

There is (or at least has been) also the convention that the top folder
of a tarball has the same name (case-sensitive) as the tarball (without
.tar{,.gz,.bz2}, and probably also dropping the version, starting with
the first dash). So while there's no problem with mIxEdcAsE package
names, they have to be *consistent* on proper filesystems I think.

We for example recently had trouble with Python, in sage-spkg properly
setting up the source folder for building. (Upstream changed from
lower- to uppercase in the folder name IIRC.)

Not sure how robust sage-spkg meanwhile is.

All folders (package names) in build/pkgs/ are lowercase though; and we
obviously shouldn't have *different* packages "foo" and "Foo" or "FOO", say.


-leif

[John H Palmieri]

On Thursday, April 30, 2015 at 2:43:43 AM UTC-7, Jeroen Demeyer wrote:

On 2015-04-30 08:57, Emmanuel Charpentier wrote:
> The Developer's guide
> <http://www.sagemath.org/doc/developer/packaging.html#directory-structure>
> states the ported packages' tarballs have to be in *lower case* :
> "The build scripts and associated files are in a subdirectory
> SAGE_ROOT/build/pkgs/package, where you replace package with a
> lower-case version of the upstream project name."
That's about the directory in build/pkgs, not the tarball name.

>  1. What other parts of the build system are broken by mixedCased tarballs ?
No part of the build system is broken by mixedCased tarball.

Although anyone who upgrades a package like Pillow may have issues when running 'sage-fix-pkg-checksums', because that script assumes that the tarball and directory names match exactly (although "Pillow" and "pillow" are treated as matching on OS X). Should we modify that script to allow mixed case tarballs, but still insist on lowercase directory names? That shouldn't be hard to do.

  John

[leif]

We should certainly fix-sage-fix-pkg-checksums.


There's btw. another inconsistency (IMHO), e.g.:

./sage -i Pillow

vs.

./sage -i pillow

Which of the above will succeed? Guess and try yourself... ;-)


(Note that there are (optional) "legacy spkgs" which aren't all
lowercase, so having all lowercase for "new-style" [s]pkg names although
the upstream tarball may be different while for the former slightly
different rules apply is a bit confusing. Try for example 'sage -i
{TOPCOM,topcom,TopCom}'...)


-leif

[Emmanuel Charpentier]

It seems that a consensus on those issues should be reached before patching anything : the different behaviors of different platforms (Macs nvs other Unices, and do not forget Windows, which is still a target...) make some assumptions hardly enforceable (or even checkable). The scripts should not rely on them.

HTH,
--
Emmanuel Charpentier

[leif]

On 04/30/2015 08:57 AM, Emmanuel Charpentier wrote:
> The sage-fix-pkg-checksums
> script, which creates packages checksums, is known not to treat
> mixedCased tarballs.

Just for the record, thanks to John P., this is fixed now:

http://trac.sagemath.org/ticket/18344

(already has positive review)


There's more we could do, but probably on further tickets.

-leif