[RFU 64bit] gmp / mpfr / mpc / ppl / isl / cloog-ppl / cloog

[Yaakov (Cygwin/X)]

On 2013-04-30 12:11, Achim Gratz wrote:
> Yaakov (Cygwin/X) writes:
>> * libraries are libfooN (containing cygfoo-N.dll) and libfoo-devel
>> (containing headers, libfoo.*, .pc files, foo-config scripts, aclocal
>> macros, etc), regardless of source tarball name.  Rationale: many
>> library sources already start with "lib", so those devel packages will
>> anyways be libfoo-devel, while having some foo-devel and some
>> libfoo-devel is just confusing; this also makes sure that the DLL and
>> devel packages are in close proximity in an alphabetical list of
>> packages.
>
> I guess this is the only rule that we might disagree about, which maybe
> hinges on the definition of "library".  For concrete example: cloog is
> mainly a library, but also comes with applications,

There are plenty of examples already in the distro, e.g.:

bzip2 => bzip2, libbz2_1, libbz2-devel
curl => curl, libcurl4, libcurl-devel
pcre => pcre, libpcre1, libpcrecpp0, etc., libpcre-devel
xz => xz, liblzma5, liblzma-devel

So too with cloog-*:

cloog-ppl => cloog-ppl, libcloog0, libcloog-devel
cloog-isl => cloog-isl, libcloog-isl4, libcloog-isl-devel

> while gmp comes with multiple libraries, but splitting the devel packages
 > across those lib* packages seems silly.

As does ppl, which I use as an example in one of my "rules".

>  Some documentation might be about a particular
> library API only, but more often it contains general information as well
> as API information, so again splitting the doc isn't doable.

Of course it's doable; use $NAME-doc to contain all "extra" 
documentation from package $NAME.

> Lastly, the debuginfo is always split onto the umbrella namespace anyway.

That is necessary because cygport doesn't attempt to create separate 
debuginfos for each binary subpackage.

> The only real change from what I did on 32bit was moving the devel packages
 > to the umbrella name and dropping the lib suffix from mpc.

The rationale for my first "rule" explains why libfoo-devel is a better 
choice IMO.  Also, in the aforementioned case of a source with both a 
library and a frontend, foo-devel would be even more confusing because 
it would not pull in foo but libfooN.

As for mpc, there is a reason for renaming the source package:

http://cygwin.com/ml/cygwin-apps/2009-04/msg00086.html

It seems I forgot that we went with mpclib instead of libmpc, not that 
it really matters given that only the source package goes by that name.

>> That being said, the naming scheme used for the 32-bit packages, as
>> well as the 64-bit packages I uploaded during the bootstrap stage, are
>> basically conforming to these "rules", with the possible exception of
>> the -doc packages (which I wouldn't make a big deal about).
>
> Yes, the doc packages were missing on 64bit, no big deal.  But the
> naming on 64bit was also different than the existing naming on 32bit.

Besides the ABI version bumps, only ppl-devel was renamed to 
libppl-devel in accordance with my "rules".

> I still think this is more consistent than what was there before or what
> would have been the result of converging it to your rules or the 32bit
> packages or trying to do both.  But I don't see the point of further
> arguing, so please let me know what to rename in the above list (and
> how) and I'll do it.

I would prefer that we stick with the naming used for the existing 64bit 
packages, which would not require a bunch of renamings on the 32bit side 
either.


Yaakov