I vaguely remember it being something about having a -devel package?
I'm asking because Festival is currently built for both archs, and there's really no reason. I've made it multiarch compatible (bug #228315), but really, there's no good reason for it to be, since nothing links with it.
The only program that requires it, in fact, is gnome-speech, and that communicates via a forked process. It's really meant to be used that way or as a network server.
In fact, I'm not sure it's even terribly useful to ship a devel package for this -- it's really not designed for things to be built against it in that way. You can add modules, but the intended process is to build them as part of the main package build. (Arguably the speech-tools libraries could be split off into a completely separate package and then festival built against _those_ devel packages, but the festival build process wants an incestuous sort of availability of the speech-tools source tree, so that's not really an option.) So if ditching the devel package is what it takes....
On Thu, 15 Mar 2007 17:38:46 -0400, Matthew Miller wrote:
I vaguely remember it being something about having a -devel package?
Yes.
Extras development: All i386 -devel packages (also virtual ones) and their dependency chains are copied into the x86_64 repository unless the -devel package is black-listed. Additionally, white-listed packages and their dep-chains are copied.
For Extras <= 6 it's just the "wine" packages.
For Core I've heard about a white-list that is updated from time to time and about ongoing work in the multi-lib area.
On Thu, Mar 15, 2007 at 11:10:57PM +0100, Michael Schwendt wrote:
Extras development: All i386 -devel packages (also virtual ones) and their dependency chains are copied into the x86_64 repository unless the -devel package is black-listed. Additionally, white-listed packages and their dep-chains are copied.
How hard is it to get a program added to the blacklist? Festival probably should be. And then I should do:
%ifarch x86_64 Obsoletes: festival.i386 < 1.96 %endif
yeah?
On Thursday 15 March 2007 22:08:59 Matthew Miller wrote:
How hard is it to get a program added to the blacklist? Festival probably should be. And then I should do: %ifarch x86_64 Obsoletes: festival.i386 < 1.96 %endif
First, I don't think you can reference arch like that in a spec.
Secondly, why don't you split out the two libs into a festival-libs package, that is required by festival? festival-devel will pick up the library requires out of the -libs package, the libs package will have a generic requires on festival, not an arch specific one. This will leave festival-devel and festival-libs as multiarch, while festival itself is not. This is the solution that many other packages use.
On Thu, Mar 15, 2007 at 10:26:09PM -0400, Jesse Keating wrote:
How hard is it to get a program added to the blacklist? Festival probably should be. And then I should do: %ifarch x86_64 Obsoletes: festival.i386 < 1.96 %endif
First, I don't think you can reference arch like that in a spec.
My understanding is that you can, as of 4.4.1.
Secondly, why don't you split out the two libs into a festival-libs package, that is required by festival? festival-devel will pick up the library requires out of the -libs package, the libs package will have a generic requires on festival, not an arch specific one. This will leave festival-devel and festival-libs as multiarch, while festival itself is not. This is the solution that many other packages use.
Hmmmm. Y'know, actually, I've already done that in the updated package. Well then. That's less annoying. :)
But, I think I'll still need the above incantation to make upgrades work cleanly, right? Because otherwise, there'll be no upgrade target for the previous festival.i386 package on x86_64 systems. Or am I not thinking straight? It's been a long day.
On another front, it turns out that there's a "libFestival.a" which hasn't been packaged for several years which would really need to be included for the devel package to be useful _at all_. Still thinking about what to do about that. :)
On Thursday 15 March 2007 22:42:30 Matthew Miller wrote:
My understanding is that you can, as of 4.4.1.
Hrm, I know you can on the cli, rpm -q foo.i386 rpm -e bar.x86_64, but you couldn't do arch specific things in the spec, like BuildRequires glibc.i386 or some such.
On Thu, Mar 15, 2007 at 10:48:33PM -0400, Jesse Keating wrote:
My understanding is that you can, as of 4.4.1.
Hrm, I know you can on the cli, rpm -q foo.i386 rpm -e bar.x86_64, but you couldn't do arch specific things in the spec, like BuildRequires glibc.i386 or some such.
The changes file says "use package color as Obsoletes: color", which I guess may mean that obsoletes now _only_ affect their own arch, not all archs. I suppose I'll test and find out.
Otherwise, what's the solution?
On Thu, Mar 15, 2007 at 11:05:20PM -0400, Jesse Keating wrote:
Otherwise, what's the solution?
I'm not sure :/
%ifarch i386 %post cat << EOF > /etc/cron.daily/ditch386.sh #!/bin/bash if [ "$( rpm -q festival.i386 --qf 'true')" == "true" ]; then if [ "$( rpm -q festival.x86_64 --qf 'true')" == "true" ]; then rpm -e festival.i386 if [ "$( rpm -q festival.i386 --qf 'true')" != "true" ]; then rm /etc/cron.daily/ditch386.sh fi; fi; fi EOF chmod +x /etc/cron.daily/ditch386.sh
%endif
Okay, I should go to sleep.
:)
On Thu, Mar 15, 2007 at 10:48:33PM -0400, Jesse Keating wrote:
My understanding is that you can, as of 4.4.1.
Hrm, I know you can on the cli, rpm -q foo.i386 rpm -e bar.x86_64, but you couldn't do arch specific things in the spec, like BuildRequires glibc.i386 or some such.
Okay, so I can confirm that this doesn't work.
However, it turns out that my package update has rearranged things enough so that there's no conflict. So the worst that happens is cruft, not a conflict during upgrade.
On Thu, 15 Mar 2007 22:26:09 -0400, Jesse Keating wrote:
On Thursday 15 March 2007 22:08:59 Matthew Miller wrote:
How hard is it to get a program added to the blacklist? Festival probably should be. And then I should do: %ifarch x86_64 Obsoletes: festival.i386 < 1.96 %endif
First, I don't think you can reference arch like that in a spec.
Secondly, why don't you split out the two libs into a festival-libs package, that is required by festival? festival-devel will pick up the library requires out of the -libs package, the libs package will have a generic requires on festival, not an arch specific one.
If festival-libs required festival, the split would be pointless as we first would need to create a multi-lib resolver that works like that and implements a well-defined way and/or copies yum's exact behaviour.
If foo-devel.i386 requires bar-devel and bar-devel is provided by bar.x86_64 as well as bar.i386, what happens?
If foo-devel.i386 requires foo = %version-release, the spec can't require foo.i386, so would foo.x86_64 also be sufficient?
The split would be pointless on a single arch, too, as festival-libs would always pull in festival. Unless there is a typo in your comment.
This will leave festival-devel and festival-libs as multiarch, while festival itself is not. This is the solution that many other packages use.
On Fri, Mar 16, 2007 at 08:08:54AM +0100, Michael Schwendt wrote:
If festival-libs required festival, the split would be pointless as we
It wouldn't, though.