broken deps outside of packagers control

[Michael Schwendt]

On Thu, 19 Apr 2007 07:39:10 +0200, Hans de Goede wrote:

> No this sounds like a BAD solution to me. We are going to have this problem for 
> every non noarch perl / python / ruby / xxx package that happens to split of a 
> -devel package (for example because of .pc files). The proper solution is to 
> either:
> 1) make the push script smarter
> 2) use a blacklist
> 
> Also notice that gnumeric-devel is not a full devel package, it contains a .so 
> symlink but no header files as libspreadsheet.so.xxx so far is intended for use 
> by gnumeric only. Besides that it contains an .idl file. I've always been 
> amazed about the split-off of a seperate devel package for these 2 files (1 
> symlink and file actually) but that is how I inhereted things from core.

Highly questionable packaging, and with a brief look I also find
issues:

  /usr/lib/bonobo/servers/GNOME_Gnumeric.server

It points to a non-existant  /usr/libexec/gnumeric-component  executable
as well as an unexpanded  @prefix@/bin/gnumeric

Splitting off the single .idl file isn't justified. The idl file itself
builds fine (whether it would work at run-time is another question), but
currently, the Gnumeric component is broken. The *.so symlink is of no
use without any API for the library. The -devel package need not require
the main package.

> Notice that fixing this won't help as the #@$%^#@ push-script

Stay nice, please. The Fedora community should stay a friendly place.

> will also put 
> .i386 packages in the x86_64 tree if they have a virtual -devel provides, and 
> if I nuke the -devel package, the main package will provide -devel for those 
> depending on it.

Nothing wrong about that. Virtual packages are not hidden. They can be
used in dependencies and are visible to users, too.
 
> Now in the case of gnumeric probably nothing is depending on the -devel, so I 
> could just nuke the -devel without adding the virtual provides. But I _refuse_ 
> todo this as this is bad packaging. Once a package is out there people should 
> be able to count on it offering a consistent "interface". Even more important I 
> _refuse_ todo this because its the push-script that needs fixing, not gnumeric.
> 

No. The pushscript makes available the i386 development packages for
x86_64, so you can develop for i386 on x86_64.