[CentOS-devel] SIG repo layout and conflicts between projects within a SIG

On Tue, Jan 20, 2015 at 8:47 AM, Lalatendu Mohanty <lmohanty at redhat.com> wrote:
> On 01/20/2015 12:03 AM, Sven Kieske wrote:
>>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> On 19.01.2015 13:40, Lalatendu Mohanty wrote:
>>>
>>> I like #1, even if it is more work. I think it is logical thing to
>>> do as SIGs should not conflict with each other when a user consumes
>>> them. I mean one of the purpose of SIGs to improve the user
>>> experience for consuming stuffs that are not present in CentOS
>>> core.
>>
>> Being not a sig member but a user:
>>
>> I dislike option 1 for several reasons:
>>
>> 1. it complicates development a _lot_
>> 2. I can't imagine any usecase where you e.g.
>> want to mix xen-kernel with ovirt, as ovirt
>> has no xen support (yet), so those don't need
>> to be compatible (at least for now).
>
>
> What about an use-case where Xen would be used with Storage SIG i.e.
> GlusterFS or Ceph or OpenAFS? Also Ovirt can be used for management of
> GlusterFS.

Cross-repo compatbility is along-standing problem. There isrt of a
solution by using the "include" option in yum.conf to include
something like '/etc/yum.excludes/[repo.exclude] to apply a set of
excludes for the entire yum configuration. I've used this to protect
the EPEL from RPMforge overlapping components, especially mismatched
"nagios-plugins" and perl modules. The reason it does not work now
with setting up /etc/yum.repos.d/[name].repo files is because those
can't provide exclusions for the base configuration, or other
repositories.

A more flexible includes structure for yum, much like the individual
repo files but not restricted to actual repositories, could help this
a lot.

>> 3. possibly adding more bloat:
>> in order to satisfy this one-repo-for-all
>> you might need to define some silly dependencies
>> (libvirt requiring xen-kernel, when you don't
>> need xen-kernel, but just ovirt/kvm).
>
>
> Honestly I don't want to complicate stuff but just concerned that user does
> not face these kind of issues when he tries to use multiple SIGs.
>
> -Lala

See above. It would take one 'includes' line added to /etc/yum.conf,
and a practice of allowing one repo's "repo-reelease" package to add
exclusions. This would be enormously helpful for things like
alternative MySQL repositories: activating the 'mysql-libe' exclusion
to prevent that dependency from being "included" and updated by the
Percona or MariaDB packages has been a configuration nightmare. In
this case, it should be possible to exclude the default Xen packages
from RHEL or CentOS and to enable the separate Xen repo kernels in an
appropriate, possibly designated sub-repository with only the kernels
and an "include" option.

That's a package management issue. Now, whether this much work on Xen
makes any sense when Red Hat is explicitly pursuing KVM support is not
so clear to me. Personally, I'd much rather see the effort spent on
making virt-manager more sane, and network configuration tools for
virtual hosts. Xen hypervisors, and other virtualization tools, all
need pair-bonding, VLAN tagging, and some of them need network bridge
configuration. *NONE* of the current generation of network
configuration tools support these for either the hyperviros or for the
virtual hosts. If someone out there with GUI design skills wants to
work on that, I'd be thrilled to help support that for all
virtualization environments.

But that's me. (And yes, I'm pretty familiar with Xen: I published the
first publicly available RPM's for it back in 2007.)