As preface some oneliner result:
[tkloczko@domek SPECS.fedora]$ for i in el4 el5 el6 el7 rhel centos epel; do echo -n "$i "; grep '%{?'$i * | wc -l; done el4 10 el5 243 el6 265 el7 281 rhel 5428 centos 239 epel 45
1) Shortly I'm going to create PR with mass change request to remove all EL4 and EL5 conditional builds as EL{5,6} are no longer supported.
2) Looks like in recent months number of new/updated EPEL EL6/EL7 packages dropped down to between few to about 20 a month with sometimes tents thousands a month Fedora updates on master weight/cost of all EPEL %ifings is few magnitudes higher than real outcome.
FTR: I'm going to add this to final list of arguments/facts why all EPEL maintenance should be moved to branches when I'll be sending email with list of arguments about why EPEL support should be removed from master.
3) When PR with request to remove from master EL{4,5} support will be finished I'm going to raise next mass change request will be about remove all <= F25 as all those Fedora versions as well should be no longer supported on master.
4) I think that Fedora procedures should be updated when some older version passes EOS. Just after this automatically should be dome mass update removing support such EOSed version.
5) kind of proposal about change general policy In many specs I found some commented lines with notes like "Remove before F<number>".
[tkloczko@domek SPECS.fedora]$ grep -i "remove before f" * | wc -l 161
I think that making such notes should be forbidden and exact set of lines should be wrapped by %ifing (without addition comments), This will make cyclic all legacy stuff cleanups easier/possible to perform using very simple script/oneliner. Q: is it enough to raise next PR about update Fedora doc about above?
6) I think that all %{rhel} %ifings should be removed or replaced by %{el6} and %{el7}. Reason: it duplicated description of the same things. Q: PR?
7) Like in 6) the same is with %{epel} %ifings
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.
Next will try to have closer look on %{rhel}, %{epel} and %{centos} %ifings to form more and/or more precise conclusions/observations.
kloczek
On 21 January 2018 at 15:54, Tomasz Kłoczko kloczko.tomasz@gmail.com wrote:
As preface some oneliner result:
- 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.
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.
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.
Next will try to have closer look on %{rhel}, %{epel} and %{centos} %ifings to form more and/or more precise conclusions/observations.
kloczek
Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org
On Sun, Jan 21, 2018 at 10:10 PM, Stephen John Smoogen smooge@gmail.com wrote:
On 21 January 2018 at 15:54, Tomasz Kłoczko kloczko.tomasz@gmail.com wrote:
As preface some oneliner result:
- 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.
On 22 January 2018 at 03:39, Neal Gompa ngompa13@gmail.com wrote: [..]
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.
Of curse that it is not that bad :D
If you want I can show some example single spec can be used to build el6, el7, Fedora, Amazon Linux and .. even Solaris 11.3 native IPS packages Solaris pkgbuild (it is quite simple perl script) uses rpm spec to describe whole build process and at the end is generating from spec %files .p5m file which is used kind of buildroot base directory on export to IPS repository. In IPS packages exist only in repo and there is no such thing like package as the file/archinve. IPS allows export package to file which can only be used to import in other repository. Single package can support more than one architecture so for example as well sharing files like documentation on install the same package in 32 and 64 ABI is not a problem. If you want you can peak on such multiarch package manifes in repo: http://pkg.oracle.com/solaris/release/manifest/0/file%2Fmc@4.8.13%2C5.11-0.1... In this manifest lines you can find:
file ba41c36ccd08352201bb13c6409ab013de19a308 chash=26520b34314cc2b0577809090182bd9a8c81d0d1 elfarch=i386 elfbits=64 elfhash=37e0b220d4cde4870763be86ac3ad6269586d02e group=bin mode=0555 owner=root path=usr/bin/mc pkg.csize=680939 pkg.size=1995352 variant.arch=i386
and
file e8067864f4ada9ebb89de4118d51b60a3210f416 chash=f4b47ddfbb250c35a9613e320ca8225ef6e0cc07 elfarch=sparc elfbits=64 elfhash=1fbb23058504895c30bd6e2eed284a6f4374b12c group=bin mode=0555 owner=root path=usr/bin/mc pkg.csize=666593 pkg.size=1698664 variant.arch=sparc
Which describes file on exactly the same path but in two arch .. all in single package. As the same repository can keep multiple versions of the same package automatically IPS repo shares/duplicates those files which have not been changed between versions.
So (back to the subject) as you see it is really "aren't that bad". There are only few not good consequences: - as long as after upgrade package package to new and you have no possibility instantly test all supported in spec distros or OSes sooner or later some variants will be dead - it is not possible to do such things on large scale because lets say if such universal spec will be OK on Fedora but it will be failing on other distros/OSess sooner or later people will start thinking that such universality is not advantage but disadvantage/obstacle as it adds some additional chunk of man/hour to maintain single package. - keeping all variants in healthy state requires from all packagers at least basic knowledge/skills on use/maintain other distros/OSess.
Writing universal spec will be kind "good intention" however some saying says that "the road to hell is paved with good intentions".
For example distance between SLE and RH/Fedora in methodologies and macros suits is so big that transferring source packages is not possible. Some time Fedora decided to spread all possible to use rpm macros from redhat-rpm-config maaany development packages which can provide some subsets of new macros. Only this (and nothing more) started even bigger split between Fedora and all other rpm distros as now no one is able to control or review in single package all possible to use macros. IMO it will take few year for all Fedora packages to realize how bad such decision was (even for only Fedora).
Nevertheless all this is way off-topic of my original email :)
kloczek -- Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH
----- Mail original ----- De: "Neal Gompa"
the main issue is what RPM features
are supported for each target distribution. Making things less ugly for gracefully degrading would be very nice. :)
Well it would be really nice if someone @downstream watched for Fedora packaging guidelines changes and made sure the prerequisites were merged downstream (every time it's just tooling enhancements, not a major glibc release of course)
This would do wonders for the whole ecosystem velocity
Regards,
On 22 January 2018 at 03:39, Neal Gompa ngompa13@gmail.com wrote: [..]
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. :)
As long as you are joking I'm ONE HUNDRED PERCENT sure that is is not true and I can prove this 😀
Proof: When I've been leading PLD development I had around few really talented and brilliant people. In many occasions, we found that standard rpm set of macros have some issues or those macros had not enough functionalities. So completely institutionally we started adding some macros or patching those macros. For quite long time we have been trying to push as much as possible to rpm original source code, You may don't know this but guess who exactly for example discovered %bcond .. Pawel Gajda or Arkadiusz Miśkiewicz (probably second one but I may be wrong). Only when handling %bcond has been accepted and provided by original rpm in relatively short time we started using it in many specs files. So yes .. %bcond it is/was ORIGINAL PLD invention. %bcond handling it is/was only two lines patch!! After this was second patch next two lines with %{with <foo>{:<str>}, %{without <foo>[:<str>]}
Even today after ~15 years integrate %bcond in rpm many Fedora packagers are refusing patches switching to %bcond. Another PLD useful %bcond related feature about how it was used .. IN PLD %bconds declaration was ALWAYS on the top of the spec after first (commented) line (with CVC/RCS tokens). In Fedora %bconds declarations is possible to find almost EVERYWHERE OK .. in most cases it is on the top but there is no Fedora standardization about indenting those declarations which usually makes those declarations not easy to read and quickly understand.
The similar history was with many other things like start populating LDFLAGS, CFLAGS, CPPFLAGS, FFLAGS to %configure. The same was with pushing CC, CXX ant other. In CVS repo with all specs we had example.spec file which was necessary to modify/update if something new was introduced. This spec had no single line of comment and was used as reference for other committers how to use some features/macros, how to format spec in Fedora there is no such self-explanatory spec and all crucial details are spread across many different corners of the Fedora documentation. Because all those details are not on the single web page there is some number of contradictions in such documentation.
Back to PLD and what caused so many variations of using this software ..
Initially, %confiigure was only "naked" macro wrapping configure and some set of --dir<foo>=%{_dir<foo>}. Initially many --dir<foo>=%{_dir<foo>} mapping was missing and in PLD first started fixing this and pushing to the rpm source tree .. Since we've integrated those changes in RPM it started speeding like a fire across other distributions. From this time in PLD comes exact way of overwriting those flags and compilers/linker like:
%configure \ CFLAGS="<flags>" \ LDFLAGS="<flags>" \ <other configure switches>
Why it was and IMO still IS!! *better* than using sometimes few exports before %configure? 🤔 Because if it was an issue caused by altering those flags in the exact package it WAS ALWAYS possible to *guess* where something needs to be fixed (even typo)!!! Instead of asking yourself "bl*dy he*ll .. where those altering compilation/linking flags is? .. in which one export line and how fare before %configure?😨". No .. no such losing the time!!!
GUYS .. STANDARD SPECS FORMAT/INDENTATION saves a lot of time even for single packager!!! This is why I've mentioned about this few times in last few days (in slightly different contexts) and *trust me I'll be nagging* about this on any possible occasion 😎 This may speed up whole Fedora development DRAMATICALLY!!! despite other "deposits" of such development improvement which I'm already trying to explore ..
So .. I would be really glad to see in Fedora specs like ONLY above altering %configure as it is in above example. Why? because this precise place in specs where using editor we need to jump to correct those altering😎
Again "ab ovo" .. So what was the strategy or real movements of the RedHat people? I may be not 100% correct but I think that just before rewrite rpm from perl to C they've started to ignore what is in standard macros set and they formed redhat-rpm-config package which is just dropping few files in some directories which are overwriting. I'm not sure why RH stopped pushing own macros to rpm source tree .. JFDI? lack of proper communication and understanding rpm developer needs of large-scale using rpm? Usual Linux NIH syndrome or just fact that quite early into rpm main "macros" file has been added possibility to include at the end per distribution extensions?
I think that because those standard macros at this time started to require very frequent/instant changes it was easier to split all macros to own macros file and maintain them inside the distribution. However, I may be not fully right and it may be as well the mixture of other above reasons.
======= So I think that real disaster started when SuSE started using rpm and it was necessary to answer on some influential people JFDINs!!! At this exact point in rpm history started real kind of disaster .. =======
OK .. sorry to be so off-topic on my own thread 😕
Please come back to add some missing facts about my original 6 out of 8 points 🙄 If you cannot find some answers maybe you can pull sleeves one of your colleagues .. telling him "dude I think you should read this" 😎
kloczek
On 22 January 2018 at 03:10, Stephen John Smoogen smooge@gmail.com wrote:
On 21 January 2018 at 15:54, Tomasz Kłoczko kloczko.tomasz@gmail.com wrote:
[..]
- 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.
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.
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.
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.
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.
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 :)
kloczek
On Mon, Jan 22, 2018 at 12:29 AM, Tomasz Kłoczko kloczko.tomasz@gmail.com wrote:
On 22 January 2018 at 03:10, Stephen John Smoogen smooge@gmail.com wrote:
On 21 January 2018 at 15:54, Tomasz Kłoczko kloczko.tomasz@gmail.com wrote:
[..]
- 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...
[2]: https://src.fedoraproject.org/rpms/rust-packaging/blob/master/f/rust-packagi...
[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.
On 22 January 2018 at 12:10, Neal Gompa ngompa13@gmail.com wrote:
<<<part about CentOS %ifings>>> [..]
- 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.
[..]
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.
So again .. +1 to a) to remove all %{centos} macros and %ifings using those macros 😀 You just said that none of the CentOS developers are pushing back any changes to Fedora because they are using as baseline RHEL, and RHEL only every few years (+5yeas to be more precise) are shapshoting Fedora to start next major EL release ..
<<<part about Mageia %ifings>>>
[..]
This is not completely true. Actually, a good number of spec files in Mageia differ from Fedora only in three things:
- %mkrel 1 instead of 1%{?dist}
- Indentation (sometimes, I personally don't mess with that)
- libification (each shared library gets its own subpackage)
Point 2 is deal breaker and only by this Mageia packages have closed way completely to start contributing back to some changes Fedora on specs level.
Mageia has many only in this distribution found patches. Let's say it straight: Mageia people have 0/NULL added value to on development if they would enforcing people pushing back ANY changes. If someone will be pushing on porting back they ill slow down own development to snail speed.
Those three points are not only difference. Mageia has own %changelog. Look on attached rust-packaging.spec.diff. Even in case this quite simple spec
BTW. adding %mkrel was IMO stupidest ever thing possible to do because all what was necessary to do was change ONLY %dist macro VALUE to mga7 or mga6 instead introducing yet-another-our-own-olny macro. I see here NIH syndrome 😎
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).
But it has nothing to do with sharing specs. Really .. it is end of story. Sorry ..
The package for RPM in Mageia is also designed to be able to build on
Fedora,
Even it it is possible for some non-empty set of specs what I saw already is enough to it will be few obstacles in macros suit. I'm sure that it will be already quite big number of such specs files which will fail. More important is that we are talking almost 100% specs which are already in Fedora so borrowing them from Mageia will be probably last thing about which typical joe-Fedora-packager will be thinking. Do you see this?
and our packaging is pretty much synchronized with Fedora's.
Show me some example(s). How this synchronization is done and Fedora specs are only used on occasions like "OK they've (Fedora) added this or updated package <foo> so we will to the same something simillar". During this process no one is using git on "borrowing" fedora specs diffs (between older and new version of the Fedora spec). Am I right? As result if someone from Mageia will be able to update some packages quicker than it will happen in Fedora NO-ONE-WILL-CARE about pushing back to Fedora similar update Am I right? Above is even probably used as kind of the argument to convince end users use Mageia in something like: "look we are Better(tm) than Fedora!" 😀 (it is nothing wrong with this .. it is just marketing) Am I right?
If it will be three times "yes" it ill be straight prove that connection between Fedora and Mageia is not *bidirectional* but whole stuff goes only in *one direction*!! Do you see it now? If it is true it is only necessary argument to remove Mageia %ifings from Fedora master.
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.
Sorry to not trusting you As long checking this took me few seconds (look on the attachment) I know that it is not true. Look on rust-packaging version 4 and 5 in Fedora and Mageia. There is no what so ever connections here .. If you will compare those two versions you will see that on update Mageia rust-packaging to version 5 no one has been using as baseline Fedora changes done in meantime.
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.
packaging/current/SPECS/rust-packaging.spec?revision=1194478&view=markup
master/f/rust-packaging.spec
Do you know that in Fedora is +20k specs? You are talking about T-H-R-E-E specs!! Please .. looking on only rust-packaging spec I'm 100% sure that no one in Mageia on releasing new version is dropping own version of the spec and again is using as baseline Fedora one. Do you see this?
[..]
We have our own copies in Mageia because it's dumb not to.
Let me guess .. BecauseWeCan(tm)? 😉 But seriously .. because there is no standard format/indentation in Fedora and at least some critical mass of Mageia packages FULLY understand HOW IMPORTANT it is!!! even if if was never openly told/verbalized?
[..]
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
First: I don't who more should I engage? 😎
Nevertheless bottom conclusion: Sorry to say that buy still you did not gave me any reason to not wipe out all Mageia %ifing (from only 3 pecs!!!) from Fedora set. The same is (so far) in case CentOS %ifings.
kloczek
On 22 January 2018 at 00:29, Tomasz Kłoczko kloczko.tomasz@gmail.com wrote:
On 22 January 2018 at 03:10, Stephen John Smoogen smooge@gmail.com wrote:
On 21 January 2018 at 15:54, Tomasz Kłoczko kloczko.tomasz@gmail.com wrote:
[..]
- 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 I didn't. It is clear that our versions of English are not syncing up so I am not sure how to communicate clearly with you. You think I am reading in between the lines, but I think I am reading what you are saying as direct and to the point of what you are wanting to do. However they are not matching up and you seem to be taking offence when I was thinking I was being helpful. Since that isn't happening, I am ending my part of the conversation until such time as I can figure out how to communicate better with you.
On 22 January 2018 at 15:53, Stephen John Smoogen smooge@gmail.com wrote: [,,]
OK so here you just gave me +1 for a). Thx.
No I didn't. It is clear that our versions of English are not syncing up so I am not sure how to communicate clearly with you. You think I am reading in between the lines, but I think I am reading what you are saying as direct and to the point of what you are wanting to do. However they are not matching up and you seem to be taking offence when I was thinking I was being helpful. Since that isn't happening, I am ending my part of the conversation until such time as I can figure out how to communicate better with you.
Why you are using rhetoric ("argumentum ad hominem/personam" to be more precise) against me and not using exact specs from CentOS showing that I'm wrong? Maybe it is not obvious but rhetoric newer was, isn't and never will be toll of proving/disproving anything. It is pure distracting tool and I know how to recognize it .. instantly. *If you don't know what you just used here is the explanation/description * https://en.wikipedia.org/wiki/Ad_hominem
Yes, my English is not perfect buy how I'm using English has nothing to do with subject, CentOS and/or Fedora specs files. Isn't it?
So back to subject. Show me pairs of Fedora and CentOS specs files. This ONLY few ways which can change result of the discussion. Just for the record: during discussions we should be using arguments or counterarguments. No impressions, no "I", no "you", ways thinking, guesses. assumptions .. etc. Just pure facts .. *please*. If you agree to stand on such platform you don't even need English to communicate with me. Use example spec files. It is really so simple.
Other possible way which you can use. Try to answer on below questions.
Are you one of the few persons who added in the past to Fedora specs CentOS %ifings? Do you know what was the propose of those %ifings? In what kind of context they have been used? Is this context still applicable to current state of the Fedora and CentOS? Are those %ifings still in use by someone?
kloczek
On 22 January 2018 at 12:21, Tomasz Kłoczko kloczko.tomasz@gmail.com wrote:
On 22 January 2018 at 15:53, Stephen John Smoogen smooge@gmail.com wrote: [,,]
OK so here you just gave me +1 for a). Thx.
No I didn't. It is clear that our versions of English are not syncing up so I am not sure how to communicate clearly with you. You think I am reading in between the lines, but I think I am reading what you are saying as direct and to the point of what you are wanting to do. However they are not matching up and you seem to be taking offence when I was thinking I was being helpful. Since that isn't happening, I am ending my part of the conversation until such time as I can figure out how to communicate better with you.
Why you are using rhetoric ("argumentum ad hominem/personam" to be more precise) against me and not using exact specs from CentOS showing that I'm wrong?
I am not meaning to use rhetoric tricks, and I will try to be clearer.
I am saying that interpreting my statements as giving you a +1 is wrong. Nothing about what you proposed earlier. If I am going to give you a +1 I will do so clearly and with my own typing. Taking my words out of context is all I am disagreeing with you.
That said, I am not agreeing with you either. We have a trilogic position. +1 I agree, 0 I have not made up my mind, -1 I disagree. I am at 0 . I have reservations mainly out of a history of dealing with the n hundred Fedora maintainers on past cleanups and how many times the cleanup fails not because the fix wasn't needed but because the people pushing the fix didn't do the groundwork needed. That groundwork is not about showing how bad stuff is or how illogical something is. It has to do with convincing N hundred developers that they have less work and more control if they do it the new way.
The reason I want to know is that it is a lot of work and it depends on how the proposer deals with people who can't see exactly what the proposer is saying. When it works it goes well. When it does not it is just constant garbage battles and flame wars. The problem I am seeing here is that I am someone who knows what work you have done in PLD and have been very much wanting to work with you on better packaging for years. I have looked at what you did for some package and then moved it over to a spec file I needed when I ran into some sort of problem. You should have had no problem convincing me that what you want is a good idea. Instead I am at the point of screaming obscenities at my keyboard.
----- Mail original ----- De: "Stephen John Smoogen"
They pull in what they want to make it work and could give a care if it is readable to anyone else.
The problem is that past a certain point those become effectively unmaintainable and start dragging Fedora in the EL blackhole instead of Fedora pulling EL forward.
It's real easy to get there, just accumulate enough EL-related cruft making any change is a PITA, and then hope 'something' in the next EL will clean up things (it won't because Fedora is El's upstream and reverting the relationship deadlocks)
Regards,
On Jan 22, 2018 11:32, nicolas.mailhot@laposte.net wrote:
----- Mail original ----- De: "Stephen John Smoogen"
They pull in what they want to make it work and could give a care if it is readable to anyone else.
The problem is that past a certain point those become effectively unmaintainable and start dragging Fedora in the EL blackhole instead of Fedora pulling EL forward.
My thoughts exactly. By maintaining "compatibility" with downstream/ other distros at any cost, no meaningful improvements can ever be made, because fedora's downstreams won't implement new things earlier than fedora itself.
I'm particularly looking forward to improvements regarding golang. The automated .spec generation is nice for getting new packages started, but maintaining those packages currently is a small nightmare in itself due to brittle scripts and a ton of unnecessary, nested conditionals.
Fabio
It's real easy to get there, just accumulate enough EL-related cruft making any change is a PITA, and then hope 'something' in the next EL will clean up things (it won't because Fedora is El's upstream and reverting the relationship deadlocks)
Regards,
-- Nicolas Mailhot _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org
----- Mail original ----- De: "Fabio Valentini"
Hi,
I'm particularly looking forward to improvements regarding golang. The automated .spec generation is nice for getting new packages started, but maintaining those packages currently is a small nightmare in itself due to brittle scripts and a ton of unnecessary, nested conditionals.
FYI, I've already posted a Go packaging guidelines update that removes most of those scripts and conditionals, and will post soonish a spec dump that implements those updates on a ~420 spec set, and updates the golang core to current golang/x/foo, current APIs for most cloud services, current grpc, all with mostly complete unbundling and working inter-package autodeps.
To give an idea of the cope, I count 489 Go source packages in Fedora right now. So that's a reboot weighting 86% the Fedora Go universe, even though it's an overlapping set, not a subset of what's in Fedora
(I could publish it sooner if people are interested in contributing to finishing up the bootstrap, the big item not completely done is moby and its deps)
And then that will be a take it or leave it, if no one's interested I'll finish my private Fedora/EL Go fork and forget about the crumbling state of Go in Fedora. And people can continue to bikeshed if using a variable named commit to hold the commit hash is ok or not. I'm certainly not interested in this conversation anymore.
Regards,
Hi,
I can get a few hundreds of those disappear if the Go packaging guidelines I posted get accepted
Otherwise, they are a symptom of technical debt accumulation in EL, nothing more
Regards,
-
Fabio Valentini -
Neal Gompa -
nicolas.mailhot＠laposte.net -
Stephen John Smoogen -
Tomasz Kłoczko