Christopher Stone wrote:
On 4/18/07, Peter Gordon <peter@xxxxxxxxxxxxxxxx> wrote:
On Wed, 2007-04-18 at 19:59 +0200, Hans de Goede wrote:
> In that case can gnumeric please be blacklisted, and the i386
version removed
> from the x86_64 repo?
>
> Thanks & regards,
>
> Hans
Unfortunately, it's not that simple - gnumeric-devel is a proper
subpackage of gnumeric, and as a good -devel subpackage, it properly
requires its base package - which means you'll have gnumeric installed
twice in a multilib setup, for each of these two arches.
A potential way to ease this is to split out a -libs subpackage which
contains the shared libraries (which are the things a -devel package
really needs), then make both the base package and the -devel subpackage
depend on it via a fully-versioned Requires tag. (See, for example, my
recent split of the openbox packaging.)
Then, gnumeric and gnumeric-devel would depend on gnumeric-libs, but you
would have only one instance of gnumeric installed (for the parent
arch).
Hope that helps.
Hans does this sound good to you? My pygame package has the same fate
and so far the best solution presented to me was to just remove the
devel package and bundle everything in a single package (because no
one ever uses pygame-devel presumably). This sounds like a better
solution to me however.
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.
Notice that fixing this won't help as the #@$%^#@ push-script 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.
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.
Regards,
Hans
--
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
