sparse 0.2 is out now, and includes header files and a static libsparse.a, but doesn't include a libsparse.so. Jeff Garzik in particular requested the static lib and headers for a project he's working on.
So, I added a -devel package and put in the header files and sparse.pc. I've also put libsparse.a in there, but see the proposal for a -static package.
Questions:
1) need -devel have a Requires: %{name}-%{version}-${release} if that doesn't include a shared library? I wouldn't think so, but it's a "Must" in the guidelines.
2) need I create a -static package for the static library?
3) if yes, should -static have a Requires: %{name}-devel-%{version}-%{release}? Should this go in the recommendations for all -static packages?
Thanks, Matt
On Tue, 2006-12-05 at 16:34 -0600, Matt Domsch wrote:
sparse 0.2 is out now, and includes header files and a static libsparse.a, but doesn't include a libsparse.so. Jeff Garzik in particular requested the static lib and headers for a project he's working on.
Can you patch sparse so that it builds a shared lib? This would be the ideal scenario.
~spot
On Tue, Dec 05, 2006 at 04:39:33PM -0600, Tom 'spot' Callaway wrote:
On Tue, 2006-12-05 at 16:34 -0600, Matt Domsch wrote:
sparse 0.2 is out now, and includes header files and a static libsparse.a, but doesn't include a libsparse.so. Jeff Garzik in particular requested the static lib and headers for a project he's working on.
Can you patch sparse so that it builds a shared lib? This would be the ideal scenario.
Could, yes. This thread (ending here): http://marc.theaimsgroup.com/?l=linux-sparse&m=116330177006275&w=2
notes that sparse as a library isn't really stable at this point, and upstream isn't terribly interested in doing soname bumps all the time, starting compat packages, etc.
On Tue, Dec 05, 2006 at 04:34:28PM -0600, Matt Domsch wrote:
need I create a -static package for the static library?
if yes, should -static have a Requires: %{name}-devel-%{version}-%{release}? Should this go in the recommendations for all -static packages?
static subpackages have been discussed a bit in the recent past, but not by the packaging group. IMHO they make sense if static libs are to be part of the build for whatever reason, but we don't have any rules about it, not even about the naming, e.g. whether it should be called foo-static, foo-devel-static, foo-static-devel and so on. At any rate the "static" subpackage would have to require the conventional devel package to get access to the headers, so 3) above goes w/o saying.
But first we would need to decide on how to handle static content in general, e.g. first decide on subpackaging it and then how the packages are to be handled.
Just to catch any such discussion beforehand: *Whether* something needs to be statically linked or not, is a policy that is not decided by the packaging committee - we just consider the *how*s and let the *why*s to fesco and core. ;)
To cut a long story short: Matt, if you do need a static lib, do as you please for now - we need to sort it out first, and then we'll tell you that it needs to be done differently ;)
On Wed, 2006-12-06 at 00:32 +0100, Axel Thimm wrote:
On Tue, Dec 05, 2006 at 04:34:28PM -0600, Matt Domsch wrote:
- need -devel have a Requires: %{name}-%{version}-${release} if that
doesn't include a shared library? I wouldn't think so, but it's a "Must" in the guidelines.
What's in the %{name} package?
- need I create a -static package for the static library?
Yes.
- if yes, should -static have a Requires: %{name}-devel-%{version}-%{release}? Should this go in the recommendations for all -static packages?
I would think yes. Does anyone see a problem with doing that?
You also need to writeup your reasons for having a static library in the first place and presenting it to FESCo. The fact that Jeff Garzik wants to use it is a two edged sword -- on the one hand it means there is a need for the library. OTOH, it means that the library is going to be used by multiple programs which is what leads to the security and other problems.
The use of -static package names is supposed to help us deal with this but we know it's not a complete job.
Jeff's comment that maybe the library is special and shouldn't be subjected to the same ABI tests as the majority of libraries has merit. But we don't have any guidelines in place for that... I don't think we even have guidelines that forbid having that kind of ABI unstable library in the first place.
static subpackages have been discussed a bit in the recent past, but not by the packaging group. IMHO they make sense if static libs are to be part of the build for whatever reason, but we don't have any rules about it, not even about the naming, e.g. whether it should be called foo-static, foo-devel-static, foo-static-devel and so on. At any rate the "static" subpackage would have to require the conventional devel package to get access to the headers, so 3) above goes w/o saying.
But first we would need to decide on how to handle static content in general, e.g. first decide on subpackaging it and then how the packages are to be handled.
Just to catch any such discussion beforehand: *Whether* something needs to be statically linked or not, is a policy that is not decided by the packaging committee - we just consider the *how*s and let the *why*s to fesco and core. ;)
To cut a long story short: Matt, if you do need a static lib, do as you please for now - we need to sort it out first, and then we'll tell you that it needs to be done differently ;)
Actually, I think we voted on this: http://fedoraproject.org/wiki/PackagingDrafts/StaticLinkage
My memory is backed up by the status on: http://fedoraproject.org/wiki/Packaging/GuidelinesTodo
Ralf just needs to move the document into the Packaging tree and update the Guidelines in the proper places :-)
-Toshio
On Tue, Dec 05, 2006 at 03:59:32PM -0800, Toshio Kuratomi wrote:
On Wed, 2006-12-06 at 00:32 +0100, Axel Thimm wrote:
static subpackages have been discussed a bit in the recent past, but not by the packaging group.
Actually, I think we voted on this: http://fedoraproject.org/wiki/PackagingDrafts/StaticLinkage
My memory is backed up by the status on: http://fedoraproject.org/wiki/Packaging/GuidelinesTodo
Oops, sorry I must have missed that meeting and I'm spreading lies now (I thought I had checked all available minutes when I couldn't make it to a meeting).
But it only contains a proposal on the naming of the package, some parts like the intradependencies of subpackages should also be part of the guidelines. Maybe Ralf could extend this part?
On Wed, 2006-12-06 at 01:10 +0100, Axel Thimm wrote:
On Tue, Dec 05, 2006 at 03:59:32PM -0800, Toshio Kuratomi wrote:
On Wed, 2006-12-06 at 00:32 +0100, Axel Thimm wrote:
static subpackages have been discussed a bit in the recent past, but not by the packaging group.
Actually, I think we voted on this: http://fedoraproject.org/wiki/PackagingDrafts/StaticLinkage
My memory is backed up by the status on: http://fedoraproject.org/wiki/Packaging/GuidelinesTodo
Oops, sorry I must have missed that meeting and I'm spreading lies now (I thought I had checked all available minutes when I couldn't make it to a meeting).
But it only contains a proposal on the naming of the package, some parts like the intradependencies of subpackages should also be part of the guidelines.
This was intentional - I wanted us to focus on "-devel" and "-static" and to prevent us from getting lost into discussions on details.
Maybe Ralf could extend this part?
Could be done - C.f. my other mail.
I could add this as a "recommendation section" to the proposal, if there should be consensus about this.
However, I don't want to end up in threads discussing all glory details of sorting out "shared/commons" packages or to see people starting nit-picking on package names, packages might have inherited from their history, nor do I see much use in us trying to detail all implications this might have on packaging in practice in advance.
If there should be problems, they'll pop up sooner or later and can be solved then.
Ralf
On Tue, Dec 05, 2006 at 03:59:32PM -0800, Toshio Kuratomi wrote:
You also need to writeup your reasons for having a static library in the first place and presenting it to FESCo. The fact that Jeff Garzik wants
I know this has allready been voted, but I still think that it is wrong, it is really a technical issue and not a political one as this thread once more shows. static libs are allready discouraged, I don't think it is relevant to ask fesco for inclusion of every lib, packagers should be responsible enough.
to use it is a two edged sword -- on the one hand it means there is a need for the library. OTOH, it means that the library is going to be used by multiple programs which is what leads to the security and other problems.
Is libsparse going to be involved in situations where security matters? I guess not?
-- Pat
On Tue, 2006-12-05 at 15:59 -0800, Toshio Kuratomi wrote:
On Wed, 2006-12-06 at 00:32 +0100, Axel Thimm wrote:
On Tue, Dec 05, 2006 at 04:34:28PM -0600, Matt Domsch wrote:
- need -devel have a Requires: %{name}-%{version}-${release} if that
doesn't include a shared library? I wouldn't think so, but it's a "Must" in the guidelines.
What's in the %{name} package?
- need I create a -static package for the static library?
Yes.
- if yes, should -static have a Requires: %{name}-devel-%{version}-%{release}? Should this go in the recommendations for all -static packages?
I would think yes. Does anyone see a problem with doing that?
Basically no.
The fundamental idea behind this proposal had been to * make dependencies on static libs visible. * Force packagers _really_ needing to link against static libs to "BR: *-static" in their specs. * Let packages "BR: *-devel" receive as few static libs as possible, to avoid accidentially picking up dependencies on static libs * Using and providing "*-devel" packages is supposed to be the nominal case. Using and providing "*-static" packages should be considered exceptions.
Implementation-wise this means: * headers must be provided by "*-devel" packages * static libs must be provided by "*-static" packages * shared libs must be provides by "*-devel" packages
=> We need to consider at least 3 cases:
1. packages supplying shared libs only - headers in *-devel - shared libs in *-devel
2. packages supplying shared and static libs. - headers in *-devel - shared libs in *-devel - static libs in *-static - *-static must "Requires: *-devel = %{version}-%{release}"
3. packages supplying static libs only. Here I see approaches:
3.1 - headers in *-devel - libs in *-devel - *-devel "Provides: *-static = %{version}-%{release}" IMO, this should be the nominal case.
3.2 - headers in *-static - libs in *-static - *-static "Provides: *-devel = %{version}-%{release}" I would not recommend this variant.
Additional complications can arise from "shared/common files" and from config files (E.g. some *.la's and *.pc's are not unlikely to become problematic). They need to be looked after on a case by case basis.
You also need to writeup your reasons for having a static library in the first place and presenting it to FESCo. The fact that Jeff Garzik wants to use it is a two edged sword -- on the one hand it means there is a need for the library. OTOH, it means that the library is going to be used by multiple programs which is what leads to the security and other problems.
The use of -static package names is supposed to help us deal with this but we know it's not a complete job.
Jeff's comment that maybe the library is special and shouldn't be subjected to the same ABI tests as the majority of libraries has merit. But we don't have any guidelines in place for that... I don't think we even have guidelines that forbid having that kind of ABI unstable library in the first place.
To me, the only legitimate reasons for _using_ static libs in Fedora should be technical ones. Which ones to allow should be subject of FESCO's decision.
So far, I can only imagine two: - Upstream doesn't provide them (Adding shared libs to a package upstream ships static libs only, is a different issue - Often it's more problematic than useful). - Correct function of an applications being used by Fedora requires it.
Allowing people to _ship_ static libs in addition to shared libs is a yet another issue. Except that it voids the "reduce Fedora bloat" aspect of the rationale, it's not much of a technical problem for Fedora itself, but a political issue.
static subpackages have been discussed a bit in the recent past, but not by the packaging group. IMHO they make sense if static libs are to be part of the build for whatever reason, but we don't have any rules about it, not even about the naming, e.g. whether it should be called foo-static, foo-devel-static, foo-static-devel and so on. At any rate the "static" subpackage would have to require the conventional devel package to get access to the headers, so 3) above goes w/o saying.
But first we would need to decide on how to handle static content in general, e.g. first decide on subpackaging it and then how the packages are to be handled.
Just to catch any such discussion beforehand: *Whether* something needs to be statically linked or not, is a policy that is not decided by the packaging committee - we just consider the *how*s and let the *why*s to fesco and core. ;)
To cut a long story short: Matt, if you do need a static lib, do as you please for now - we need to sort it out first, and then we'll tell you that it needs to be done differently ;)
Actually, I think we voted on this: http://fedoraproject.org/wiki/PackagingDrafts/StaticLinkage
Yes, FPC had voted unanimously (all attending members voted for it. Ca. 7 out of 9 members had been present), but I don't recall if Axel had been present.
All this took place before Ulrich Drepper jumped onto the wagon and before the "Fedora Summit", so ...
My memory is backed up by the status on: http://fedoraproject.org/wiki/Packaging/GuidelinesTodo
Ralf just needs to move the document into the Packaging tree and update the Guidelines in the proper places :-)
Am I supposed to do so? I thought somebody was to supposed to present this to FESCO and then he would give me a ping to merge it or he would merge it. Anyway, no problem, I can merge it, when I can find a free time slot.
Ralf
On Wed, Dec 06, 2006 at 04:58:03AM +0100, Ralf Corsepius wrote:
3.1
- headers in *-devel
- libs in *-devel
- *-devel "Provides: *-static = %{version}-%{release}"
IMO, this should be the nominal case.
OK, I've done this instead now.
3.2
- headers in *-static
- libs in *-static
- *-static "Provides: *-devel = %{version}-%{release}"
I would not recommend this variant.
Additional complications can arise from "shared/common files" and from config files (E.g. some *.la's and *.pc's are not unlikely to become problematic). They need to be looked after on a case by case basis.
It's annoying that the .pc file includes a libdir=/usr/lib64, else a -devel (without the .a) could be noarch. :-( As it stands, we won't be able to install the -devel as multi-arch because all the .h files will conflict.
On Tue, 2006-12-05 at 22:53 -0600, Matt Domsch wrote:
On Wed, Dec 06, 2006 at 04:58:03AM +0100, Ralf Corsepius wrote:
Additional complications can arise from "shared/common files" and from config files (E.g. some *.la's and *.pc's are not unlikely to become problematic). They need to be looked after on a case by case basis.
It's annoying that the .pc file includes a libdir=/usr/lib64, else a -devel (without the .a) could be noarch. :-( As it stands, we won't be able to install the -devel as multi-arch because all the .h files will conflict.
Even then it can't be noarch. rpm(build) doesn't allow different archs for different subpackages.
-Toshio
On Tue, Dec 05, 2006 at 10:53:41PM -0600, Matt Domsch wrote:
On Wed, Dec 06, 2006 at 04:58:03AM +0100, Ralf Corsepius wrote:
3.1
- headers in *-devel
- libs in *-devel
- *-devel "Provides: *-static = %{version}-%{release}"
IMO, this should be the nominal case.
OK, I've done this instead now.
http://domsch.com/linux/fedora/extras/sparse/0.2/ now has the spec I'm planning to use and RPMs that are built from it. I'd appreciate a sanity check based on this conversation.
What's the process to take this to FESCo for approval?
Thanks, Matt
On Tue, Dec 05, 2006 at 03:59:32PM -0800, Toshio Kuratomi wrote:
On Wed, 2006-12-06 at 00:32 +0100, Axel Thimm wrote:
On Tue, Dec 05, 2006 at 04:34:28PM -0600, Matt Domsch wrote:
- need -devel have a Requires: %{name}-%{version}-${release} if that
doesn't include a shared library? I wouldn't think so, but it's a "Must" in the guidelines.
What's in the %{name} package?
$ rpm -qpl sparse-0.2-1.x86_64.rpm /usr/bin/cgcc /usr/bin/sparse /usr/share/doc/sparse-0.2 /usr/share/doc/sparse-0.2/FAQ /usr/share/doc/sparse-0.2/LICENSE /usr/share/doc/sparse-0.2/README
i.e. no libsparse.so, and nothing that a -devel package needs. So I don't see the need for a dependency here.
- need I create a -static package for the static library?
Yes.
- if yes, should -static have a Requires: %{name}-devel-%{version}-%{release}? Should this go in the recommendations for all -static packages?
I would think yes. Does anyone see a problem with doing that?
So 3 is yes, no real problem there. Here's what -devel provides:
$ rpm -qpl sparse-devel-0.2-1.x86_64.rpm /usr/include/sparse /usr/include/sparse/allocate.h /usr/include/sparse/bitmap.h /usr/include/sparse/compat.h /usr/include/sparse/dissect.h /usr/include/sparse/expression.h /usr/include/sparse/flow.h /usr/include/sparse/ident-list.h /usr/include/sparse/lib.h /usr/include/sparse/linearize.h /usr/include/sparse/parse.h /usr/include/sparse/ptrlist.h /usr/include/sparse/scope.h /usr/include/sparse/storage.h /usr/include/sparse/symbol.h /usr/include/sparse/target.h /usr/include/sparse/token.h /usr/lib64/libsparse.a /usr/lib64/pkgconfig/sparse.pc /usr/share/doc/sparse-devel-0.2 /usr/share/doc/sparse-devel-0.2/LICENSE
but I'll move libsparse.a into its own -static package.
You also need to writeup your reasons for having a static library in the first place and presenting it to FESCo. The fact that Jeff Garzik wants to use it is a two edged sword -- on the one hand it means there is a need for the library. OTOH, it means that the library is going to be used by multiple programs which is what leads to the security and other problems.
as noted, it's not a big security concern for this development app usage.
The use of -static package names is supposed to help us deal with this but we know it's not a complete job.
Jeff's comment that maybe the library is special and shouldn't be subjected to the same ABI tests as the majority of libraries has merit. But we don't have any guidelines in place for that... I don't think we even have guidelines that forbid having that kind of ABI unstable library in the first place.
It's the instability of the API/ABI that keeps the project from wanting to expose a versioned shared library. That's more work than it's ready to maintain; Jeff's fine with it being fluid and changing his own app accordingly. I hadn't packaged the shared lib in earlier versions because nothing else needed it; now that something does, that doesn't mean the API needs to be versioned, except that shared libs would require that overhead.
Thanks, Matt
On Tue, 2006-12-05 at 22:44 -0600, Matt Domsch wrote:
Here's what -devel provides:
$ rpm -qpl sparse-devel-0.2-1.x86_64.rpm ... /usr/lib64/libsparse.a /usr/lib64/pkgconfig/sparse.pc ...
but I'll move libsparse.a into its own -static package.
What about the pkg-config file? Where should that go? Since there's no shared library, the -devel package is pretty useless without the -static package. Until there is a shared library maybe the -devel package should require the -static package (and vice-versa).
Jeff
Matt_Domsch@dell.com (Matt Domsch) writes:
- need -devel have a Requires: %{name}-%{version}-${release} if that
doesn't include a shared library? I wouldn't think so, but it's a "Must" in the guidelines. ... 3) if yes, should -static have a Requires: %{name}-devel-%{version}-%{release}? Should this go in the recommendations for all -static packages?
-static (and -debuginfo) are good candidates for:
| Conflicts: %name < %version-%release | Conflicts: %name > %version-%release
This prevents version mix without adding unneeded Requires:
Enrico
packaging@lists.fedoraproject.org