On Tue, 2006-09-05 at 08:45 -0500, Josh Boyer wrote:
> You all realize that the amount of time spent on this thread so far is
> about 10x greater than it would have been to just fix the packages to
> match the policy, right?
It's important to understand why a policy exists. Then you can question
whether it applies to all the circumstances it states or come up with a
better way of achieving the end-goal. And that can lead to better
guidelines.
In this case I'm leaning towards changing the rules because it seems the
reason for the policy might not apply to Mono packages:
Mono packages contain two type of pkgconfig files. One type is for C
glue libraries that link C code and Mono code. These should be treated
just like normal pkgconfig files and be placed into a -devel subpackage
along with the C headers and .so file. This is what is done in
libbeagle and libbeagle-devel (subpackages of beagle), for instance.
The other type is for programs linking together Mono libraries. In this
case, the .pc will have lines which look like this (cut from banshee):
Requires: gtk-sharp-2.0 gconf-sharp-2.0
Libs: -r:/usr/lib64/banshee/Banshee.Base.dll \
-r:/usr/lib64/banshee/Banshee.Widgets.dll \
-r:/usr/lib64/banshee/entagged-sharp.dll \
-r:/usr/lib64/banshee/hal-sharp.dll \
-r:/usr/lib64/banshee/MusicBrainz.dll -r:Mono.Posix
The Libs: line refers to Mono .dll files which are needed at runtime as
well as build time. The Requires: line references other Mono pkgconfig
files which are similar. These files do not appear to drag in
dependencies on C pkg-config files and their -devel packages. AFAICS,
by their nature, they never will (alexl, please correct me if that is
incorrect.)
So a mono package with only a pkgconfig file as development information
won't drag in -devel type information from other packages.
Now we have Ralf's point. A package may have other types of information
that qualify as -devel at some later point in time (api doc, for
instance) or it may depend on a package which later gains the same and
needs to split off a devel package. For the specific case of docs, I
think we'd want to split large development documentation into its own
-doc or -apidoc subpackage anyway.
For the general case there is a bit of trouble. Say foo-1.0.pc
Requires: bar-1.0.pc Requires: baz-1.0. When I initially package this
there is no other devel information so all is well. But down the road
baz adds more developer-relevant information. Suddenly, foo is pulling
in files it shouldn't on end-user systems.
How can we work around this?
1) Do as the guideline suggests. .pc files go in a separate -devel
subpackage.
2) Make an exception for packages whose only -devel type file is a .pc
so they can stay the way they are. Add Matthias Saou's suggested
virtual Provides: %{name}-devel = %{version}-%{release} and have
consumers of pkgconfig files use the virtual provides. If other -devel
type files are added we make the virtual provide into a real subpackage.
Other packages which depend on the package for their pkgconfig files
have to periodically check for the existence of real -devel packages and
if they exist, spawn new -devel packages of their own that just have a
single pkgconfig file and the dependencies on the -devel otherwise the
runtime package will drag in the pkgconfig dependency tree.
3) Make an exception for packages whose only -devel type file is a .pc
so they can stay the way they are. If other -devel type files are
added, we have to split off a new subpackage and fix all the
BuildRequires: in dependent packages to point to the new -devel. Every
package that has a Require on that package because of pkgconfig
dependencies has to grow a -devel package with just the pkgconfig file
inside it and the proper dependencies otherwise the pkgconfig files will
break.
4) For Mono applications, pkgconfig files that deal with informing the
mono build chain of the location of the .dlls belong in the main
package. Other -devel files belong in a subpackage.
I think #1 is the most robust solution and the friendliest to reviewers
because there are fewer special cases. #2 is going to result in too
much work for packagers (who have to watch for their dependent packages
changing) and reviewers.
#3 requires reviewers to understand the special case of pkgconfig files
not dragging in extra dependencies but allows us to stop having
"ridiculous" single file subpackages in many cases. It requires
packagers to fix their packages if a -devel package is created further
up the dep chain (so if glib-sharp grew the need for a -devel package,
the whole gtk stack would need to be changed to have -devel packages.)
Reviewers and packagers must understand that mono packages can have
pkgconfig files for the C bindings and for the mono .dll and they need
to be treated differently.
#4 is kludgy as written because it only applies to packages written in
Mono rather than being generalizable to packages which have/don't have a
certain feature. But we have certain unwritten guidelines which are
similar (In python, we could put .py files from %{python_sitelib} into a
-devel or -debuginfo package because they are not needed for running the
programs but we don't) It is directly opposite to the treatment of
pkgconfig files from C (in C, pkgconfig files MUST go in a -devel
subpackage. In Mono, pkgconfig files MUST be placed in the main
package.) It requires reviewers and packagers to understand that mono
packages may have two different sets of pkgconfig files with different
rules. This supposes that a mono pkgconfig file will only drag in files
that are also needed at runtime. (alexl, please correct me if I'm
wrong.)
I think #1 is the best for clarity. But I would also be willing to see
the rule revised to something like #3 or #4 because I don't think most
mono packages are going to have -devel files other than the pkgconfig
file (alexl, please correct me if you see this differently.) Compared
against each other, I think #3's major drawback is psychological: mono
packagers may be hesitant to create -devel subpackages because the
change will cascade to other packages, causing more work. #4's main
drawback is its direct conflict with the guidelines for C pkgconfig
files.
-Toshio
Attachment:
signature.asc
Description: This is a digitally signed message part
-- Fedora-maintainers mailing list Fedora-maintainers@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-maintainers
-- Fedora-maintainers-readonly mailing list Fedora-maintainers-readonly@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-maintainers-readonly
