Re: post-jessie: header only C++ library package (static?)
On Sun, Oct 19, 2014 at 08:45:04PM +, Sune Vuorela wrote: On 2014-10-19, Rene Engelhard r...@debian.org wrote: On Sun, Oct 19, 2014 at 04:39:20PM +0200, Jerome BENOIT wrote: What I know of is - large parts of boost and - seqan. If you are looking for samples: mpfrc++ [1] can be added. And mdds. And parts of libvigraimpex. And I am just packaging rapidjson... Eigen. glm (libglm-dev). And there's prbably much more.. And I bet most ttheir r-deps don't use Built-Using: I know from LO (uses boost, vigraimpex, mdds, glm and soon rapidjsono via collada2gltf) at least. Regards, Rene -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141021100039.gd3...@rene-engelhard.de
Re: post-jessie: header only C++ library package (static?)
On Sun, 19 Oct 2014, Sune Vuorela wrote: Eigen. Yes, that was it. Thanks. OK, we have some examples, I hope this helps the OP ;-) bye, //mirabilos -- Sometimes they [people] care too much: pretty printers [and syntax highligh- ting, d.A.] mechanically produce pretty output that accentuates irrelevant detail in the program, which is as sensible as putting all the prepositions in English text in bold font. -- Rob Pike in Notes on Programming in C -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/alpine.deb.2.11.1410201135160.7...@tglase.lan.tarent.de
Re: post-jessie: header only C++ library package (static?)
Hi,
On Sat, Oct 18, 2014 at 09:23:56PM +0100, Dimitri John Ledkov wrote:
Hello,
On 18 October 2014 17:19, Osamu Aoki os...@debian.org wrote:
Hi,
This is about packaging around a header only C++ library package.
...
header only C++ library package seems to be more common.
As I see the replies
trie data structure of marisa (my problem)
large portion of boost(Dimitri)
STL (Dimitri)
seqan
Eigen
mpfrc++
mdds (parts of libvigraimpex)
rapidjson
Do we have some mechanism to track such situation?
If we don't, maybe we should have similar rules.
A large portion of boost is static only libraries. Similarly STL comes
to mind as well. The danger in those are transitive API/ABI breaks,
e.g. whilst compiling foo against newer template works, it becomes
API/ABI incompatible with foo build against older template version.
This is in part, why each new boost release is packaged with new
name-versioned packages in debian.
I see. This also forces its depended packages to be updated when these
name-versioned packages are removed from the archive. Interesting.
Anyway, it seems we just need to be diligent to update depended packages
manually for now.
I don't believe we consistently binNMU packages that build depend on
templates only, simply by virtue that they are not caught/tracked by
the binary transition tracker (or the auto-generator of thereof).
I see. By the way, I have never seen package using Build-Using in
debian/control which is documented in policy. Is there any automatic
way to set the used-source:Version of package used? Something like ...
Built-Using: marisa (== ${used-source:Version})
I can not find example stanza...
Automatic API/ABI tracking should help here, as presented by me at
Debconf 2014, but I haven't yet set that up.
URL?
Osamu
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141020141224.GB2630@goofy.local
generate Built-Using headers (was Re: post-jessie: header only C++ library package (static?))
On Mon, 20 Oct 2014, Osamu Aoki wrote:
I see. By the way, I have never seen package using Build-Using in
debian/control which is documented in policy. Is there any automatic
way to set the used-source:Version of package used? Something like ...
Built-Using: marisa (== ${used-source:Version})
I can not find example stanza...
Unfortunately no.
mksh does this, but it’s rather complicated because of the way
the binaries in mksh are built (they can either depend on glibc
or klibc or dietlibc (actually, even two out of the three) plus
possibly gcc and possibly linux-libc-dev (klibc)).
The gist is:
debian/control contains:
| Built-Using: ${mksh:B-U}
The code generates (as a shell variable) the dependencies and
makes them available to dpkg-gencontrol by…
| echo mksh:B-U=$buspkgs builddir/substvars
… which is then later (in binary-arch) added:
| cat builddir/substvars debian/mksh.substvars
Now, what *is* in $buspkgs you ask?
Complicated.
In my case, I have two things that I track to go into B-U:
① filenames, for example $($CC -print-libgcc-file-name),
i.e. /usr/lib/gcc/x86_64-linux-gnux32/4.9/libgcc.a
② package names, for example dietlibc-dev (must be installed)
But B-U wants *source* package names! So what to do:
ⓐ resolve filenames from ① to binary package names:
filename=$($CC -print-libgcc-file-name)# from above
filename=$(readlink -f $filename)# realpath()ise
x=$(dpkg -S $filename)
binpkg=${x%%: *}
ⓑ put list of binary packages from ⓐ and ② together
ⓒ resolve them into source packages:
binpkgs='libgcc-4.9-dev:x32 dietlibc-dev' # from above
for x in $binpkgs; do
dpkg-query -Wf '${source:Package} (= ${source:Version})\n' $x
done | sort -u | {
buspkgs=
while IFS= read -r x; do
test -n $x || continue
test x$x = x (= ) continue
echo Built Using: $x
test -z $buspkgs || buspkgs=$buspkgs,
buspkgs=$buspkgs$x
done
echo mksh:B-U=$buspkgs builddir/substvars
}
There you have that line from above again. The code is a bit
complicated, but it ensures that every source package is only
referenced once (more nicely) and skips missing things.
All of this is POSIX sh safe, Debian Policy §10.4 compliant,
and works with bash, dash, mksh. (Note that shells are allowed
to differ what parts of “a | b | c” run in subshells and what
parts, if any, run in the main shell. Hence, the echo *must*
be inside the {…} behind the pipe; the $buspkgs variable may
be unset after the closing ‘}’!)
In your case, it’s probably much simpler. You have one binary
package, I think, for which you will want to record the source
package and its precise version number.
HTH HAND,
//mirabilos
--
«MyISAM tables -will- get corrupted eventually. This is a fact of life. »
“mysql is about as much database as ms access” – “MSSQL at least descends
from a database” “it's a rebranded SyBase” “MySQL however was born from a
flatfile and went downhill from there” – “at least jetDB doesn’t claim to
be a database” ‣‣‣ Please, http://deb.li/mysql and MariaDB, finally die!
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/alpine.deb.2.11.1410201726220.7...@tglase.lan.tarent.de
Re: post-jessie: header only C++ library package (static?)
Hi,
On Mon, Oct 20, 2014 at 11:12:24PM +0900, Osamu Aoki wrote:
header only C++ library package seems to be more common.
As I see the replies
trie data structure of marisa (my problem)
large portion of boost(Dimitri)
STL (Dimitri)
seqan
Eigen
mpfrc++
mdds (parts of libvigraimpex)
Two different packages :)
mdds
parts of libvgraimpex
but yes :)
And then there are static-only libraries. I didn't even start on those ;)
I see. By the way, I have never seen package using Build-Using in
debian/control which is documented in policy. Is there any automatic
way to set the used-source:Version of package used? Something like ...
Built-Using: marisa (== ${used-source:Version})
I can not find example stanza...
No, and last I looked the wording in policy matched also other libs
and the working was unclear/too broad so I simply ignored it.
If it changed
Regards,
Rene
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141020192200.ga3...@rene-engelhard.de
Re: post-jessie: header only C++ library package (static?)
On Sun, 19 Oct 2014, Osamu Aoki wrote: This is about packaging around a header only C++ library package. IIRC, we already have one in the archive. I vaguely recall it from m68k porter work, but can’t remember the name. Something mathematical, I think? bye, //mirabilos -- 15:41⎜Lo-lan-do:#fusionforge Somebody write a testsuite for helloworld :-) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/alpine.deb.2.11.1410191529100.1...@tglase.lan.tarent.de
Re: post-jessie: header only C++ library package (static?)
On Sun, Oct 19, 2014 at 03:30:17PM +0200, Thorsten Glaser wrote: On Sun, 19 Oct 2014, Osamu Aoki wrote: This is about packaging around a header only C++ library package. IIRC, we already have one in the archive. I vaguely recall it from m68k porter work, but can’t remember the name. Something mathematical, I think? What I know of is - large parts of boost and - seqan. Bastian -- The sooner our happiness together begins, the longer it will last. -- Miramanee, The Paradise Syndrome, stardate 4842.6 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141019140743.ga9...@mail.waldi.eu.org
Re: post-jessie: header only C++ library package (static?)
On 19/10/14 16:07, Bastian Blank wrote: On Sun, Oct 19, 2014 at 03:30:17PM +0200, Thorsten Glaser wrote: On Sun, 19 Oct 2014, Osamu Aoki wrote: This is about packaging around a header only C++ library package. IIRC, we already have one in the archive. I vaguely recall it from m68k porter work, but can’t remember the name. Something mathematical, I think? What I know of is - large parts of boost and - seqan. If you are looking for samples: mpfrc++ [1] can be added. Bastian [1] https://packages.qa.debian.org/m/mpfrc%2B%2B.html -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5443cd18.3050...@rezozer.net
Re: post-jessie: header only C++ library package (static?)
On Sun, Oct 19, 2014 at 04:39:20PM +0200, Jerome BENOIT wrote: On 19/10/14 16:07, Bastian Blank wrote: On Sun, Oct 19, 2014 at 03:30:17PM +0200, Thorsten Glaser wrote: On Sun, 19 Oct 2014, Osamu Aoki wrote: This is about packaging around a header only C++ library package. IIRC, we already have one in the archive. I vaguely recall it from m68k porter work, but can’t remember the name. Something mathematical, I think? What I know of is - large parts of boost and - seqan. If you are looking for samples: mpfrc++ [1] can be added. And mdds. And parts of libvigraimpex. And I am just packaging rapidjson... Regards, Rene -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141019203538.ga10...@rene-engelhard.de
Re: post-jessie: header only C++ library package (static?)
On 2014-10-19, Rene Engelhard r...@debian.org wrote: On Sun, Oct 19, 2014 at 04:39:20PM +0200, Jerome BENOIT wrote: What I know of is - large parts of boost and - seqan. If you are looking for samples: mpfrc++ [1] can be added. And mdds. And parts of libvigraimpex. And I am just packaging rapidjson... Eigen. /Sune -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/m217sg$nte$1...@ger.gmane.org
post-jessie: header only C++ library package (static?)
Hi, This is about packaging around a header only C++ library package. As I understand, Debian does not usually ship static libraries based on policy 8.3 Static libraries. At the same time, Debian does not impose any systematic way to let us trace upload of the static library and alike. https://www.debian.org/doc/debian-policy/ch-sharedlibs.html#s-sharedlibs-static I happen to read Fedora Packaging guideline on this topic and found out that they enforce to package static libraries in a separate *-static package. So whenever a *-static is updated, they can trace and rebuild packages build-depending on such a *-static package. http://fedoraproject.org/wiki/Packaging:Guidelines#Packaging_Static_Libraries Since we expect practically all programs should not link to the static library, I thought that the Debian situation is not too bad. I thought that we should be able to manage situation with rare cases of bin-NMUs for some special packages. Then I saw Packaging Header Only Libraries for C++. http://fedoraproject.org/wiki/Packaging:Guidelines#Packaging_Header_Only_Libraries | Certain libraries, especially some C++ template libraries, are header | only libraries. Since the code is generated during compile time, they | act just like static libraries and need to be treated as such. Fedora forces such library to use package name *-static to let all packages depending on it be traced (and rebuild as needed). It also requires such seemingly arch=all (in the Debian term) packages to be marked arch=any (in the Debian term). header only C++ library package seems to be more common. Do we have some mechanism to track such situation? If we don't, maybe we should have similar rules. Regards, Osamu PS: This is something to consider for post-Jessie. Some of my packages are linked to a such C++ header only library (marisa). -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141018161931.GA18862@goofy.local
Re: post-jessie: header only C++ library package (static?)
On 2014-10-18, Osamu Aoki os...@debian.org wrote: Do we have some mechanism to track such situation? No automatic one if the maintainer of the 'using' package is unaware of it. If the maintainer is aware, we have the Built-Using mechanism. /Sune -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/m1u5rs$l2b$1...@ger.gmane.org
Re: post-jessie: header only C++ library package (static?)
Hello, On 18 October 2014 17:19, Osamu Aoki os...@debian.org wrote: Hi, This is about packaging around a header only C++ library package. As I understand, Debian does not usually ship static libraries based on policy 8.3 Static libraries. At the same time, Debian does not impose any systematic way to let us trace upload of the static library and alike. https://www.debian.org/doc/debian-policy/ch-sharedlibs.html#s-sharedlibs-static I happen to read Fedora Packaging guideline on this topic and found out that they enforce to package static libraries in a separate *-static package. So whenever a *-static is updated, they can trace and rebuild packages build-depending on such a *-static package. http://fedoraproject.org/wiki/Packaging:Guidelines#Packaging_Static_Libraries Since we expect practically all programs should not link to the static library, I thought that the Debian situation is not too bad. I thought that we should be able to manage situation with rare cases of bin-NMUs for some special packages. Then I saw Packaging Header Only Libraries for C++. http://fedoraproject.org/wiki/Packaging:Guidelines#Packaging_Header_Only_Libraries | Certain libraries, especially some C++ template libraries, are header | only libraries. Since the code is generated during compile time, they | act just like static libraries and need to be treated as such. Fedora forces such library to use package name *-static to let all packages depending on it be traced (and rebuild as needed). It also requires such seemingly arch=all (in the Debian term) packages to be marked arch=any (in the Debian term). header only C++ library package seems to be more common. Do we have some mechanism to track such situation? If we don't, maybe we should have similar rules. A large portion of boost is static only libraries. Similarly STL comes to mind as well. The danger in those are transitive API/ABI breaks, e.g. whilst compiling foo against newer template works, it becomes API/ABI incompatible with foo build against older template version. This is in part, why each new boost release is packaged with new name-versioned packages in debian. I don't believe we consistently binNMU packages that build depend on templates only, simply by virtue that they are not caught/tracked by the binary transition tracker (or the auto-generator of thereof). Automatic API/ABI tracking should help here, as presented by me at Debconf 2014, but I haven't yet set that up. -- Regards, Dimitri. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CANBHLUiq98X2WG-9vGe+YDynmO95pFssFeqfZ-=9ouzm9nv...@mail.gmail.com
