On 16 February 2018 at 15:50, Stephen John Smoogen <smo...@gmail.com> wrote:
[..]
> Even before EPEL-5 was EOL, very little of Fedora would compile out of
>
the box and required massive amounts of %if and other hacks to even
> try to compile from a rawhide spec file.
>
> If someone wanted to keep compiling for EL-5 they should branch the
> code themselves and maintain it as such versus trying to keep the
> cruft in the main tree. I believe that is what arbitrary branching is
> for.
>
I think that you are not fully aware what you've just done.
You just delivered *golden argument* on why EL{6,7} changes/tweaks should
be not be kept as %ifed part of the spec on master branch.
Than you very much because you succeeded on what I've been failing so far
here!!! :D
I can only repeat yet another time that only way solving whole class of
issues like those with EL*/EPEL is NOT keeping EL{6,7} relevant changes on
rawhide master branch!
If at least one person will checkout exact older Fedora branch, do
necessary updates, test it (somehow) and will be using such updated package
it is absolute minimum guarantee that such updates may be working correct.
At the moment each package has per Fedora version branches and some of the
packages el{6,7} branches.
It is hard to understand why it is in this case such duality that on master
are integrated changes relevant to el{6,7} or older Fedora on master.
What looks like handy from point of view single package maintainer creates
whole chaos on master branch and moving forward all changes in this point
with descent speed is only by this harder and harder from point of view of
Fedora as distribution
In other words .. what looks like useful feature on single package scale is
really UNACCEPTABLE on whole distro level.
If someone still has some doubts about necessary changes just ask
yourselves what would happen if Linus would be accepting in his kernel git
repo #ifdefed parts which will be used on older kernels? such #ifdefed
parts does not make any sense as whole tree is in EXACT kernel version!!!
-> such parts never would be tested!!!
Isn't it?
Because kernel has similar number of objects (text files) as Fedora, and
needs to be maintained *as consistent set*, it delivers working example
where some future Fedora changes should go.
Some package maintainers must as well step down on Earth to spot that what
they are doing *has bigger context*.
Why? Because it is only LOGICAL way of keeping everything as *working and
consistent set*.
Q: What generally happens with Linux kernel tree when Linus releases new
non-rc main kernel version?
A: Whole tree is cloned and maintained separately by people who at least
are using exact kernel version.
EXACTLY the same methodology should be applied in case of the Fedora.
In both cases (kernel and fedora) general methodology is determined quite
frankly by VCS tooling which in both cases is git.
With proper separations will be possible to remove INSTANTLY tons of
%ifings from rawhide specs which will make all specs *way more readable*
and NOT affected by any changes in older Fedoras or EL*.
Simpler form/shorter specs -> lower possibility of mistakes and lower
effort on understand what is done in exact spec.
It lowers energy barrier on introduce large scale changes (if they will be
needed) as well on any branches.
Q.E.D.
kloczek
--
Tomasz Kłoczko | LinkedIn: *http://lnkd.in/FXPWxH <http://lnkd.in/FXPWxH>*
--
Tomasz Kłoczko | Tel: 0774 1209067 | LinkedIn: *http://lnkd.in/FXPWxH
<http://lnkd.in/FXPWxH>*
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
