Dne 25. 03. 20 v 15:19 Troy Dawson napsal(a): > On Wed, Mar 25, 2020 at 6:15 AM Nicolas Mailhot via devel > <devel@xxxxxxxxxxxxxxxxxxxxxxx> wrote: >> Le mercredi 25 mars 2020 à 13:09 +0100, Aleksandra Fedorova a écrit : >>> On Wed, Mar 25, 2020 at 12:48 PM Miro Hrončok <mhroncok@xxxxxxxxxx> >>> wrote: >>> As I mentioned in the previous mail, branching goes against the >>> purpose of the effort. >>> >>> What we like to achieve is to create a continuous flow from Fedora >>> Rawhide through branched Fedora all the way to downstream, which is >>> sometimes CentOS and sometimes EPEL. >> Then please work with @rh engineering to get an up-to-date packaging >> stack in EL (that means, latest stable Fedora rpm and latest stable >> Fedora packaging macros, and all the other things that make packager >> work less a shore). >> >> A huge amount of EL ifdefs is directly caused by the staleness of the >> packaging stack in EL. That’s why so much Fedora stuff never makes it >> in EPEL. Most people Fedora side do not want to deal with the utter >> clustefuck of trying to push complex up to date software to EL using >> inadequate obsolete tooling. >> >> No amount of clever ifdefing is going to mitigate this tooling >> staleness. No amount of poking is going to convince people that *do* >> *not* *want* *to* *deal* *with* *el* *braindamage* to accept >> braindamage side-effects in their own Fedora specs. That’s trying to >> put lipstick on a pig. >> >> We’ve been saying that to @rh representatives for years now. rpm and >> its ajuncts is the heart of community packaging. Packaging is done by >> packagers. Packaging is not done by people that loath packaging (and >> are continuously surprised their own packaging tools for people not >> interested in packaging do not see mass packager adoption). >> >> rpm state in EL prevents most downstreaming. Please focus efforts >> there. >> >> I don’t see how you will get any community adhesion in fixing >> downstream problems, if all your solutions are downstream focused, >> without caring about the people you want to enroll. >> > RHELN (currently RHEL9) is supposed to look like rawhide up to > whatever the cutover point is. So, up until that point, you shouldn't > be putting RHEL conditionals in, unless you do so for EPEL packages. > > There are exceptions to this, such as the kernel, glibc, firefox, and > a handful of others. But those are the exceptions. > > After the cutover date, then again, RHELN (in the next case it will be > RHEL10) should be looking like whatever is in rawhide, so you still > shouldn't need RHEL conditionals in, unless you do so for EPEL package > builds. > > This ELN proposal has nothing to do with older RHEL releases or EPEL. > > Troy I agree with Nicolas and Troy here. IMO the eln branch is essential for the success of this change. Every conditional prevents innovation in Fedora, because nobody knows what is the impact. Even if the CI provides feedback, that the specific change does not work in ELN, it might result in not updated package, because everybody will be afraid to touch it. That is much worse situation then if the package fails to build in ELN. Vít _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
