7:52 p.m.
Hi all,
I maintain sonic-visualiser in Fedora -- it's an audio visualization
tool that can optionally link against libmad, to support manipulating
MP3 files.
The Fedora build, naturally, has this disabled; I made it a build time
switch to quickly enable the feature. It'd be nice if it can be shipped
within RPMfusion, though, but because the package is monolithic, it can
be annoying to do -- one can't just build the full package and then
filter out the core parts, as is done with xine-lib-plugins-freeworld.
What is the recommended way. Use an obsolete? Make them both parallel
installable?
Regards,
--
Michel Salim
<SalimMA(a)fedoraproject.org>
GPG key ID: 78884778
IRC: hircus
Package Sponsor,
Fedora Project
10:35 a.m.
Using alternatives seems appropriate, but you can also rename the
binary and the .desktop file so you can have a completely parallele
installable version.
Conflicting and Obsoleting fedora maintained packages have be avoided.
2009/8/22 Michel Salim <michael.silvanus(a)gmail.com>:
Hi all,
I maintain sonic-visualiser in Fedora -- it's an audio visualization
tool that can optionally link against libmad, to support manipulating
MP3 files.
The Fedora build, naturally, has this disabled; I made it a build time
switch to quickly enable the feature. It'd be nice if it can be shipped
within RPMfusion, though, but because the package is monolithic, it can
be annoying to do -- one can't just build the full package and then
filter out the core parts, as is done with xine-lib-plugins-freeworld.
What is the recommended way. Use an obsolete? Make them both parallel
installable?
Regards,
--
Michel Salim
<SalimMA(a)fedoraproject.org>
GPG key ID: 78884778
IRC: hircus
Package Sponsor,
Fedora Project
4:53 p.m.
On Sun, 23 Aug 2009 12:35:46 +0200, Nicolas wrote:
Using alternatives seems appropriate, but you can also rename the
binary and the .desktop file so you can have a completely parallele
installable version.
Conflicting and Obsoleting fedora maintained packages have be avoided.
Nah, explicit Conflicts are fine in that case.
audacity vs. audacity-freeworld is one example.
Users need to choose between either one.
Relocating an application and all its files it may read/write just
to make it parallel-installable with another build of the same/older/newer
application is just not worth the extra effort. And if you don't relocate
or rename config/run-time files, there's the risk that this causes
side-effects since one app is built with more features than the other
one or is a different version even.
5:22 p.m.
On Sun, 2009-08-23 at 18:53 +0200, Michael Schwendt wrote:
On Sun, 23 Aug 2009 12:35:46 +0200, Nicolas wrote:
> Using alternatives seems appropriate, but you can also rename the
> binary and the .desktop file so you can have a completely parallele
> installable version.
>
> Conflicting and Obsoleting fedora maintained packages have be avoided.
Nah, explicit Conflicts are fine in that case.
audacity vs. audacity-freeworld is one example.
Users need to choose between either one.
Relocating an application and all its files it may read/write just
to make it parallel-installable with another build of the same/older/newer
application is just not worth the extra effort. And if you don't relocate
or rename config/run-time files, there's the risk that this causes
side-effects since one app is built with more features than the other
one or is a different version even.
In this case, not *too* much of an effort:
$ rpm -ql sonic-visualiser
/usr/bin/sonic-visualiser
/usr/share/applications/fedora-sonic-visualiser.desktop
/usr/share/doc/sonic-visualiser-1.6
/usr/share/doc/sonic-visualiser-1.6/COPYING
/usr/share/doc/sonic-visualiser-1.6/README
/usr/share/doc/sonic-visualiser-1.6/README.OSC
/usr/share/icons/hicolor/48x48/apps/sonic-visualiser.png
but yes, having a Conflicts: should be good enough. In this case, I
should not be using Obsoletes: and Provides:, right? Unless there are
other packages that depend on sonic-visualiser being installed, that
could make do with sonic-visualiser-freeworld.
The other concern is legality. I'm currently based in the US, so ... not
sure how much I can do this myself.
Thanks,
--
Michel
6:39 p.m.
On Sun, 2009-08-23 at 10:31 -0700, Conrad Meyer wrote:
On Sunday 23 August 2009 10:22:10 am Michel Salim wrote:
> The other concern is legality. I'm currently based in the US, so ... not
> sure how much I can do this myself.
As are many rpmfusion packagers ;).
True, that. I guess by the PGP precedence, since I only provide the
recipe for creating the package, and the build takes place on a server
overseas, it's kosher :P
OK, I created a review request for sonic-visualiser-freeworld here:
https://bugzilla.rpmfusion.org/show_bug.cgi?id=782
The corresponding Fedora package, that conflicts with this, will be
build when this one is approved. I plan to keep both in sync and build
updates concurrently.
Thanks,
--
Michel Salim
<SalimMA(a)fedoraproject.org>
GPG key ID: 78884778
IRC: hircus
Package Sponsor,
Fedora Project
5:42 p.m.
On Sun, 23 Aug 2009 13:22:10 -0400, Michel wrote:
On Sun, 2009-08-23 at 18:53 +0200, Michael Schwendt wrote:
> On Sun, 23 Aug 2009 12:35:46 +0200, Nicolas wrote:
>
> > Using alternatives seems appropriate, but you can also rename the
> > binary and the .desktop file so you can have a completely parallele
> > installable version.
> >
> > Conflicting and Obsoleting fedora maintained packages have be avoided.
>
> Nah, explicit Conflicts are fine in that case.
> audacity vs. audacity-freeworld is one example.
> Users need to choose between either one.
>
> Relocating an application and all its files it may read/write just
> to make it parallel-installable with another build of the same/older/newer
> application is just not worth the extra effort. And if you don't relocate
> or rename config/run-time files, there's the risk that this causes
> side-effects since one app is built with more features than the other
> one or is a different version even.
In this case, not *too* much of an effort:
$ rpm -ql sonic-visualiser
/usr/bin/sonic-visualiser
/usr/share/applications/fedora-sonic-visualiser.desktop
/usr/share/doc/sonic-visualiser-1.6
/usr/share/doc/sonic-visualiser-1.6/COPYING
/usr/share/doc/sonic-visualiser-1.6/README
/usr/share/doc/sonic-visualiser-1.6/README.OSC
/usr/share/icons/hicolor/48x48/apps/sonic-visualiser.png
Does it maintain config files?
but yes, having a Conflicts: should be good enough. In this case, I
should not be using Obsoletes: and Provides:, right? Unless there are
other packages that depend on sonic-visualiser being installed, that
could make do with sonic-visualiser-freeworld.
Well, it could depend on /usr/bin/sonic-visualizer instead, which
is not expensive (*bin* is covered by the primary metadata) and would
be more accurate anyway. Alternatively, provide a capability and make
dependencies require that one.
5381
days inactive
5382
days old
rpmfusion-developers@lists.rpmfusion.org
6 comments
4 participants
participants (4)
-
Conrad Meyer -
Michael Schwendt -
Michel Alexandre Salim -
Nicolas Chauvet