On Wed, Oct 17, 2012 at 12:57:31PM -0500, Greg Swift wrote:
> ...snip...
>
>> > Right. I think this may be something we want to ask the Fedora
>> > Packaging folks (who live on the packaging list) about.
>>
>> good plan
>
> Can you post over there about this and look for feedback?
I am going to. my procrastination excuse was that I was hoping to
hear from at least one more person before I did in case there was more
feedback.
There are quite a few reasons to avoid Conflicts. Some of them are listed
on the Conflicts wiki page but there are others as well. For instance, in
Fedora, we need to make the effort to be porting software forward to newer
versions of their dependencies rather than maintaining extra packages for
backwards compatibility. But EPEL doesn't need to play by the same rules if
they don't want to.
There's a basic question of cost and benefit. For Fedora, with its shorter
time to EOL, the costs of a no-Conflicts policy are less than in EPEL where
your base platform is going to be available for years. Just bear in mind
that you're going to be maintaining those compat packages for years as well.
So the costs of allowing Conflicts are also higher.
For your two initial examples, I think that you'd want to be careful about
allowing conflicts but might be able to justify it in one of the cases. You
need to ask yourself: "Would any user want to install both versions of this
package at the same time?" For an application, this may be no. For
a library, this is almost always going to be yes. To me that rules
rubygem-rspec right out as a good case for Conflicts. Collectd is also
libraries but the case could be made that they'd be coupled to whatever
version of collectd is running on the system. So you might be able to make
the case there. (But do think about things like -- what if a user has some
boxes running collectd5 and others collectd4. If these libraries were
parallel installable would they enable the user to query information from
both sets of boxes?)
-Toshio