On Jan 20, 2018 12:29, "Igor Gnatenko" <ignatenkobrain@xxxxxxxxxxxxxxxxx> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hello,
I know that many of you like to have just one branch which builds everywhere
(starting from el6), but this really slows down development of Fedora for many
years. Let me show some examples:
* File-triggers are not supported by el6/el7 RPM, so every package which has
icons should have some number of scriptlets conditionalized by %if 0%{?rhel}
&& 0%{?rhel} <= 7.
* Rich dependencies are not supported by el6/el7 RPM and YUM, so anyone who
wants to use them need to have same conditionals.
* Some of dependency generators do not exist on el*, so instead of having
BuildRequires: python3dist(foo) you need to wrap it with conditions again and
I'm working on change proposal which eliminates need of writing runtime
requirements, so one more place of conditionals.
Given all these, it is very hard to get any new feature in "production" because
everyone wants to support 10 years old thing (even if they don't think so).
Even if people hope next version of EL will be better in this, it doesn't mean
that el6/el7 can be fixed easily.
Why I'm writing this? I want to hear from you if you think it would be good to
prohibit (or advise, or whatever mechanism would work) usage if conditionals in
(at least) master branch to allow us to develop features faster. Thoughts?
Yes, please.
My reasoning:
There are many reasons why .spec files have to diverge between branches, including for:
- mass rebuilds after branching a new fedora release,
- rebuilds for .soname changes (usually in rawhide),
- bug fixes / patches specific to a certain branch,
- changed Packaging Guidelines (for example, due to obsolete scriptlets).
All this inevitably leads to diverging %changelogs, Release: tag values - and to a lot of conditionals, if the .spec files need to be kept "compatible" between branches for some reason.
In my opinion, the benefit of being able to "merge" (in quotes, because merging changelogs doesn't work) newer branches into old ones is dwarfed by the additional burden of maintaining and constantly updating all conditionals (which leads to bugs). As Igor mentioned, all rich deps, most virtual provides, most scriptlets, etc. have to be wrapped.
As a result, some packagers don't seem to care (or don't have the time) to update their packages for changed Guidelines (because adding and maintaining all those conditionals correctly is hard, I guess). This leads to .spec files for rawhide packages which don't comply with the current Packaging Guidelines - or to bugs or undesired behaviour changes. Additionally, provenpackagers and co-maintainers have to deal with the conditionals mess anyway if they want to (or have to) step in to fix occurring issues.
Suggestions?
I find it hard to track changes to the Packaging Guidelines, and when those changes are made, they sometimes only apply to certain branches (or only to rawhide), and it's no longer clear which Guidelines apply to other branches.
It would be really useful to have a wiki page outlining where the Guidelines for stable branches are different to the most recent version of the Packaging Guidelines (if such a page already exists, please ignore this and point me to it).
With this information as an authoritative source (current Guidelines for rawhide branch, and exceptions/adaptations for other branches and EPEL), we could start pointing out where .spec files (regardless of the branch) don't comply (anymore) with the applicable "version" of the Guidelines, and start to remove conditionals where they can be removed, and to report / fix issues - with little to no room for differences in "taste" or "interpretation".
Conditionals for current fedora releases aside, checks for releases that have reached EOL should be cleaned up as soon as possible anyway (I still find .spec files referencing fedora 21 or earlier sometimes) ...
TL;DR:
- We need an authoritative source that tells us packagers which Guidelines apply to which branch (or what has to be done differently - or can be done better - in, for example, f26 when compared to the current Packaging Guidelines).
- With this information, we can start cleaning up unneccessary or outdated conditionals in .spec files, and can probably remove all conditionals (depending on %{?fedora}) altogether - since IMO the maintenance burden and error-prone-ness of "compatibility" between branches is way greater than the benefit of being able to "merge" (caveat changelogs, Release tags, other changes) from newer to older releases.
- This will, over time (as changes to rawhide trickle down into what will become fedora 28/29 and fedora 29/30), lead to much simpler, less error-prone, and more easily maintainable .spec files (which benefits maintainers, co-maintainers, provenpackagers, and users).
- Independently, I think conditionals for releases older than N-2 (currently: 24 and earlier) should be removed either way, and checks for fedora < N-1 should be removed after the corresponding release reaches EOL.
Fabio
- --
- -Igor Gnatenko
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlpjJ6oACgkQaVc UvRu8
X0wp9A//Sy5KBTDJ92/D7f+P/v56V7epwRNQQAdO7ur4jRM2wAFj1ac t3OXQODgz
EfNk4EhDdQ2oR+RUzjQEgMpB4AHpP/ZHDb3wSVhx8ESu1+ l5JIBS1RVLCsq1i5Gt
B+E+eaVSoTrIOExadUAUHuWDkzD5plFusM TFSY6mJYm4FInGJ9mpt3CnW+O1C7F7
MnyEdVGMaYyyd8+GHadTg4acuHfNWbdwYAk3N0R098hIf 5YOG1XNulFWAGhXBMld
fRkuDxv0nHvew3V8A79ZNth+hGHd9HrGXr4LUDoLGgvBdNS1vkap3O +3WNUWPxra
3A7YN85HTdrYWJLnOZovgFqej4HQbSJoiW6srAUsKY+wj297bpsKJ+ BFMuEwFrN4
yWH91ihVwLtkQJ0OQgexRmWSzc4L6gMnLjx3gjc3VW8reOIptjVroUrUlUlE myO8
Sh2/PrCklUXZ0/TrgQLefVnadDZnSdEwtRD4pISn0Acg 1GBWBh58SQB8tT1mVz06
1uJgowXVA7naQ50GCk48BlRJ7XJB4YJzdmnzKmWmQtYreDjFEwQ5+ QPZwAlE8DUp
yaPFPdV4lWI/WMSc3FC1KpvPW6aHHo8YAWuyYlc1AF qwwqhr5gBFTPEUDus2D9cu
yyY8RJuCayhsXcDEDyZIU5uP4Ymv0G+m9UJq2TqSy73dLTJ9h6E=
=EaOc
-----END PGP SIGNATURE-----
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@lists.fedoraproject.org
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
