Bug 203547 - split a metacity-devel package + missing dependency
split a metacity-devel package + missing dependency
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: metacity (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Søren Sandmann Pedersen
:
Depends On:
Blocks: FC7Target 226138
  Show dependency treegraph
 
Reported: 2006-08-22 09:18 EDT by Patrice Dumas
Modified: 2014-06-18 05:08 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-04-03 12:15:03 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
split a devel subpackage and cleanups (3.02 KB, patch)
2006-11-22 07:14 EST, Patrice Dumas
no flags Details | Diff

  None (edit)
Description Patrice Dumas 2006-08-22 09:18:43 EDT
Description of problem:

a -devel package should be split out metacity, with include files,
.a, .so and pkgconfig. The -devel package should requires
gtk2-devel

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:
Comment 1 Søren Sandmann Pedersen 2006-09-06 16:41:30 EDT
Why?
Comment 2 Patrice Dumas 2006-09-06 16:51:37 EDT
In that case it is very clear, since there is a missing 
dependency on gtk2-devel seen for example in the include
files, and we certainly don't want metacity to pull in 
gtk2-devel.

Even when there is no dependency on other -devel packages
it is better to split, such that it is only possible to
link against -devel package. Otherwise, in the build root
it could be possible that unwanted libraries appear which
may be linked against in the package being built, leading 
to hard to reproduce build environments.
Comment 3 Matthias Clasen 2006-10-29 16:49:12 EST
Splitting off a -devel just for purity of packaging is a bit questionable. 
For one thing, it will suddenly make metacity multilib, for no good reason. 
Comment 4 Patrice Dumas 2006-10-30 11:08:04 EST
Fedora is also about package quality (call it purity if
you prefer). I allready said in Comment #2 why it was
better, it is not just for purity. Of course unattended
builds and right devel dependencies are not functionnality
that prevent metacity for doing its work in normal cases,
but still it has merits and help to attain better quality 
standard. Regarding having metacity-devel becoming
multilib, this seems to be something usefull, just like
for any other package or am I missing something?
Comment 5 Patrice Dumas 2006-11-17 10:57:50 EST
Maybe it is the right time to make that change
such that it leaves time to workaround things that break?

The -devel package should also 

Requires: pkgconfig
Comment 6 Søren Sandmann Pedersen 2006-11-17 14:19:44 EST
This is vastly more likely to happen quickly if a patch were to be attached to
this bug.
Comment 7 Patrice Dumas 2006-11-17 15:59:04 EST
Coming soon! I wasn't sure that it was going to be accepted, so...
Comment 8 Patrice Dumas 2006-11-22 07:14:19 EST
Created attachment 141898 [details]
split a devel subpackage and cleanups

While I was at it, I also did other cleanups. Tell
me if you prefer a patch with only the -devel changes.

- split out a devel package (#203547)
- clean %%build section and rpmlint warnings

rpmlint is almost silent now:
W: metacity non-conffile-in-etc /etc/gconf/schemas/metacity.schemas
W: metacity-devel no-documentation

I think that the static library is not very usefull in the
case of metacity.

I tested that at least gnome-python2-desktop requires 
metacity-devel as buildrequires (for gnome-python2-metacity).

repoquery --whatrequires libmetacity-private.so.0
control-center-1:2.17.1-6.fc7.i386
gnome-python2-metacity-0:2.17.1-1.fc7.i386
metacity-0:2.17.2-1.fc7.i386
compiz-0:0.3.2-2.fc7.i386
Comment 9 Matthias Clasen 2006-11-22 12:31:10 EST
It is still pretty dubious to me why we would want to have a -devel package for
some library that is explicitly hamed -libmetacity-private, indicating that it
is not meant as a stable api to develop against. 
Comment 10 Patrice Dumas 2006-11-23 06:14:44 EST
The naming of the library is irrelevant, it is used as part of
other packages build process so it should be in a devel subpackage. 
Besides it has everything development requires, headers, .so and 
pkgconfig file. If it is not meant to be used, then the headers 
directory and files, pkgconfig file and .so symlink should not be 
shipped at all.

Currently it is not possible to build gnome-python2-desktop
without metacity support because of that broken packaging.
Comment 11 Matthias Clasen 2006-11-23 21:38:52 EST
Can you explain why you think it is important that you can build
gnome-python2-desktop without metacity ?
Comment 12 Patrice Dumas 2006-11-24 03:53:39 EST
It is important to be able to chose to build gnome-python2-desktop
with or without metacity support. It shouldn't brought in 
by accident, but because there is a dependency on metacity-devel.
Chances are that we want metacity support in gnome-python2-desktop,
but it could be otherwise, somebody else doing another package may
want something else. Being able to chose the build dependencies 
is an element, admitedly not a vital one, of correct and quality 
packaging. It helps doing unattended builds.

As a side note, if you have a look at the gnome-python-desktop.spec
file, you'll notice that metacity is the only non -devel buildrequires,
so the packaging quality I am advocating is certainly not far away.
Comment 13 Patrice Dumas 2006-12-14 04:10:21 EST
Is there something wrong with the patch?
Comment 14 Søren Sandmann Pedersen 2007-03-23 12:49:36 EDT
We should resolve this by F7.
Comment 15 Patrice Dumas 2007-03-23 16:46:40 EDT
I made a patch 5 months ago, after I got the impression that
I didn't do it in vain... What is wrong with the patch?
I already proposed to remove the changes other than the devel 
split.
Comment 16 Ray Strode [halfline] 2007-03-28 15:54:34 EDT
Patrice, there isn't necessarily anything wrong with your patch (I haven't
looked at it).

We just haven't had an opportunity to get to the bug yet.  Søren said in comment
14, he's prioritizing it for fedora 7 though.
Comment 17 Matthias Clasen 2007-04-03 12:15:03 EDT
Fixed in 2.18.0-2.fc7

Note You need to log in before you can comment on or make changes to this bug.