On Sun, Jan 21, 2018 at 10:10 PM, Stephen John Smoogen <smooge@xxxxxxxxx> wrote:
> On 21 January 2018 at 15:54, Tomasz Kłoczko <kloczko.tomasz@xxxxxxxxx> wrote:
>> As preface some oneliner result:
>>
>
>> 8) Why we have %{centos} %ifings? Theoretically Centos is EL derivate up to
>> ABI level so all this should be:
>>
>> a) removed
>> b) replaced by %{el6} and %{el7} (and if it is anything older .. remove)
>> c) if ContOS guys are using Fedora gir repos to preserve some CentOS
>> specific changes they should move all this stuff to own git (create project
>> on github it is not rocket science). IMO definitely %{centos} is next
>> candidate to remove from master branch.
>>
>
> It might help to do some further research before speculating. The
> CentOS 'guys' do maintain everything in their repo. You are somehow
> assuming that other maintainers only maintain packages in Fedora for
> Fedora. They don't. They may use the same spec with slight changes in
> all kinds of subprojects and tools, and Fedora is just yet another
> operating system to them. So I would go search for all kinds of things
> like mageia, suse, even debian in the spec files as they may show up
> because the maintainer wants that spec file to work elsewhere also.
>
I will heartily second this. I do my best to minimize the
conditionals, of course, but I do regularly build spec files that
build RPMs for Fedora, Mageia, openSUSE, and of course CentOS/RHEL.
Many of my spec files will also trivially build native Debian packages
with the "debbuild" tool for Debian and Ubuntu. And at $DAYJOB, we do
this literally all the time (Fedora / Ubuntu dual capability with spec
files and OBS).
While most of the non-RPM distro stuff tends to not be in my spec
files in Fedora, nearly all of my personal ones do support it.
> The issue is that to a various developers, the package is just a step
> they need to fill out to get the package into Fedora, CentOS, RHEL,
> Mageia, etc. They pull in what they want to make it work and could
> give a care if it is readable to anyone else. They know it has to pass
> some rules, but beyond that anything that causes them more headaches
> like extra branching, etc is just a reason to tell the person who is
> pushing it to go jump in a lake. It has nothing to do with the EPEL
> project, the CentOS project, RHEL, or anything else. It has to do with
> the developer/maintainer of the package getting what they want for the
> least amount of effort because they have 10k other things they MUST
> work on instead.
>
Personally, I'd like it to be easier to make multi-distro spec files
by leveraging the increasing commonality among distributions. It's
already not that bad these days, the main issue is what RPM features
are supported for each target distribution. Making things less ugly
for gracefully degrading would be very nice. :)
> Until you, Igor and others start engaging the maintainers to
> understand why doing those things solve problems for them.. and why
> they aren't moving to newer tools.. this is not going to end well.
>
Multi-distro spec files in itself aren't that bad. In my experience,
the things that drag you down are the Debian/Ubuntu and RHEL/SLE
targets. But they eventually catch up. However, the sad reality is,
you can only go so far without improvements (i.e. backports) to older
distributions.
--
真実はいつも一つ！/ Always, there's only one truth!
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
