Martin Langhoff wrote:
As it's a single package and this could expand to a couple more
packages but no more, one alternative is to take that single package
and rename it ejabberd-xs and set it to provide:ejabberd,
conflicts:ejabberd.
If you go this route, I think what you want is obsoletes. Obsoletes says
"this packages replaces this one." Conflicts says "this package cannot
be installed at the same time as this other one."
One mechanism gives the tools instruction on how to handle things, the
other is more of an assertion that mostly just causes the end user pain
when it comes up.
Building conflicts into your repositories is generally not very
friendly. Sometimes it may make sense, but I'm not sure it makes sense here.
I am already down that path with Moodle ("moodle-xs"), which I plan to
maintain as a long-term heavily customised package.
Instead clone the Fedora repo. removing the packages you want to
"override"
Quite a bit of work if I also want to give them access to sec updates
in a timely fashion :-) and my "conflict" with Fedora packages is
tiny.
I think you could come up with a reasonably fast sync script if you
wanted to go this way.
--
Fedora-buildsys-list mailing list
Fedora-buildsys-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
