This is the mail archive of the cygwin-apps mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]