On Mon, Jan 22, 2018 at 12:29 AM, Tomasz Kłoczko
<kloczko.tomasz@xxxxxxxxx> wrote:
> On 22 January 2018 at 03:10, Stephen John Smoogen <smooge@xxxxxxxxx> wrote:
>>
>> On 21 January 2018 at 15:54, Tomasz Kłoczko <kloczko.tomasz@xxxxxxxxx>
>> wrote:
>
> [..]
>>
>> > 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.
>
>
> I've done my reserch.
> These a, b and c points are not speculations.
> They describes 3 only possibilities explanations about what needs to be
> done.
> Other facts which other people replaying on may email may only shorten this
> list os possible to do scenarios.
>
>>
>> The CentOS 'guys' do maintain everything in their repo.
>
>
> OK so here you just gave me +1 for a). Thx.
>
No he didn't. He's telling you that CentOS packages have their own
Dist-Git for packages they get from RHEL. RHEL people maintain
packages in Fedora, and those often have conditionals for everything.
>> 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.
>
>
> Please discuss this with yourself because I had no such though even for
> fraction of the second.
> Please stop reading between the lines. Please read what I wrote straight.
>
>> 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.
>
>
> So now you are assuming things taken from nowhere :)
> Just checked and all specs from Fedora master and I found 3 Fedora specs
> with Mageia %ifings.
>
> [tkloczko@domek SPECS.fedora]$ for i in mageia; do grep '%{?'$i * |awk -F\.
> '{print $1}' | uniq ; done
> mock-core-configs
> mock
> rust-packaging
>
> Just checked mock from Fedora master and Mageia.
> In Fedora is mock 1.4.8. In Mageia 1.4.2. Mageia is using completely
> different spec with removed all distro type or version %ifings.
> It is not the same spec as this one in Fedora.
> In Mageia mock-core-configs is in the same version but uses it uses
> completely different spec.
> rust-packaging as well as mock-core-configs is in the same version as in
> Fedora but again .. spec is completely different.
>
This is not completely true. Actually, a good number of spec files in
Mageia differ from Fedora only in three things:
1. %mkrel 1 instead of 1%{?dist}
2. Indentation (sometimes, I personally don't mess with that)
3. libification (each shared library gets its own subpackage)
There are many packages and package stacks synced from Fedora on a
regular basis. For example, the entire Java and MinGW stack is sourced
from Fedora, with minimal changes done. I also personally synchronize
the SELinux stack from Fedora (including selinux-policy).
I am the packager for mock and mock-core-configs in Mageia, and it
differs from Fedora only because originally the scriptlets were quite
different for detecting whether something is Mageia vs what is Fedora.
They are more similar now because I contributed that work back to the
Fedora packages. In fact, "mock-core-configs" was the name *I* came up
with, because we have extra configs for mock as "mock-mageia-configs"
and Miroslav Suchy needed a name for the package containing the split
out configs.
The entire Rust packaging stack is nearly *identical* because the
Fedora Rust SIG includes myself and Rémi Verschelde, both of whom are
also Mageia packagers. And for the Rust stack, we just add %mageia
conditionals and leave things alone, because keeping everything in
total sync is important for the maintainability of it. Fortunately,
the two distributions are more similar than different and when we're
starting from zero, we've been able to leverage RPM features from this
decade.
The package for RPM in Mageia is also designed to be able to build on
Fedora, and our packaging is pretty much synchronized with Fedora's.
Packages that are synchronized with Fedora often have "Warning: This
package is synchronized with Fedora" or "Warning: This package is
synchronized with FC" (yes, yes, Fedora Core, a thing that hasn't
existed in ten years...). There's a number of core packages with this
warning, as well as a few other random ones (like Flatpak and
whatnot).
>From time to time, we also contribute improvements to packaging from
Mageia back to Fedora, if they're wanted. Of course, now that we have
PRs, it'll be easier than when we did it via patches in Bugzilla that
no one ever looked at.
> Just one test:
>
> $ diff -u rust-packaging.spec.mageia rust-packaging.spec | diffstat
> rust-packaging.spec | 82
> ++++++++++++++++++++++++++++++++--------------------
> 1 file changed, 51 insertions(+), 31 deletions(-)
>
> Next time try to spend at least few seconds to verification something before
> forming some speculations.
>
> Thank you to point that remove Mageia %ifings is next possible (small this
> time) thing to do.
>
Trust me, I know what I'm talking about when it comes to rust-packaging.
The spec is nearly identical in Mageia[1] and Fedora[2]. In fact,
since we just imported Fedora's C.UTF-8 locale patch for glibc[3],
we're going to be able to use C.UTF-8 instead of forcing in
en_US.UTF-8 in stuff, so it'll become even more similar.
[1]: http://svnweb.mageia.org/packages/cauldron/rust-packaging/current/SPECS/rust-packaging.spec?revision=1194478&view=markup
[2]: https://src.fedoraproject.org/rpms/rust-packaging/blob/master/f/rust-packaging.spec
[3]: http://svnweb.mageia.org/packages?view=revision&revision=1195193
>>
>> 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.
>
>
> I've just checked it and it is not true.
> Mageia people are using own set of specs.
> They've done what was not possible to do up to now in Fedora.
> They are using in all specs the same indentation which is quite close to
> style which I've proposed first time more than ~24 years ago submitting
> biggest part of the packages to RHCN.
>
We have our own copies in Mageia because it's dumb not to. Just
because we source from Fedora doesn't mean we rely on Fedora Dist-Git
as a build source. Our SVN is what our build system builds from. There has
been talk of maintaining both Fedora and Mageia branches in our own
Dist-Git once we get it up and running, but for now we don't.
> Fedora has no standard on this area and most of the packagers are using
> BecauseWeCan(tm) format/indentation.
> Because Mageia people are using some standard (whatever this standard is)
> looks like they are using Fedora spec only on start maintaining some new
> packages.
> In other words by definition they cannot share results of they own work.
> Such standard on indentation is MAJOR OBSTACLE on sharing/reusing every
> change between any distributions and Fedora.
>
Mageia's historical standard is tab indentation to line things up.
Nothing really enforces this anymore. But when people do this, it
screws with the diffstat.
>> 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.
>
>
> Really sorry but this is EXACTLY what I'm doing here :)
>
Are you? You seem a little... combative for trying to engage with people.
--
真実はいつも一つ！/ Always, there's only one truth!
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
