[HN Gopher] Fedora co-mingles its source packages with Red Hat E...
___________________________________________________________________
Fedora co-mingles its source packages with Red Hat Enterprise Linux
Author : zdw
Score : 36 points
Date : 2021-06-03 05:00 UTC (18 hours ago)
(HTM) web link (utcc.utoronto.ca)
(TXT) w3m dump (utcc.utoronto.ca)
| gabereiser wrote:
| Same deal with Ubuntu and Debian. One is the upstream of the
| other so I don't really get the point.
| dralley wrote:
| There is a difference (which the author points out) but I still
| don't really see the problem.
|
| In this particular instance, yes, a change was upstreamed that
| should not have been upstreamed. But upstreaming changes _in
| general_ is a good thing, so when the author says
|
| > (This situation isn't the same as Debian and Ubuntu. Ubuntu
| uses Debian's packaging work, but Ubuntu's changes for their
| own needs don't automatically wind up in Debian.)
|
| I'm not sure I'm convinced that this is an unmitigated positive
| thing.
| tyingq wrote:
| The problem is roughly that there's a circular thing going on
| where some downstream changes become upstream ones. It resulted
| in this problem for the person writing the post:
| https://utcc.utoronto.ca/~cks/space/blog/linux/DKMSBuiltForW...
|
| Your comparison is mentioned specifically: _" This situation
| isn't the same as Debian and Ubuntu. Ubuntu uses Debian's
| packaging work, but Ubuntu's changes for their own needs don't
| automatically wind up in Debian_"
| geofft wrote:
| But the author is wrong about that and 'gabereiser is correct
| - Ubuntu has been trying to push changes in to Debian, and in
| some cases that involves pushing Ubuntu-specific conditionals
| into the Debian git repo (especially when the same people
| maintain the Debian and Ubuntu packages). See for instance
| the GCC packaging: https://salsa.debian.org/search?search=Ubu
| ntu&group_id=4586&...
| gabereiser wrote:
| I remember as early as last year pulling deb sources and
| they were full of Ubuntu-isms in a Debian tree. So it's
| exactly the same.
| richardwhiuk wrote:
| Doesn't Fedora X's RPMs basically become RHEL's RPMs? What's the
| big deal here?
| skered wrote:
| Until Red Hat starts to add backports or fixes for customers
| that don't get push back upstream. Then when X+1 gets to RHEL
| it's missing all the previous RHEL only updates (some not
| backport related).
| richardwhiuk wrote:
| Presumably everything relevant in RHEL gets backported before
| the next RHEL cut, and everything is in a branch?
| denimnerd42 wrote:
| How often does this happen? do they not keep track of what
| they need to upstream? how do they merge that all back in
| when X+1 begins? yikes..
| [deleted]
| CoolGuySteve wrote:
| I always wondered who does all this backporting and patching
| work for these ancient enterprise Linuxes. It seems like
| brutally monotonous work.
|
| Maybe they're reading this comment right now, hi!
| handrous wrote:
| Is there a world in which _the vast majority_ of dev work
| isn 't brutally monotonous? Most work's writing
| unremarkable code for unremarkable products containing
| unremarkable features that have already been implemented
| 1,000 times before, and likely even more than once before
| for the person doing the work. A ton of dev time, at least
| for people who aren't the much-derided solo-language-
| experts (e.g. The C# + Windows programmer, the Java
| programmer, who _only_ do those kinds of jobs and don 't
| even dabble in much else) is just wrangling the unfamiliar-
| brokenness of a tool & library ecosystem (it would be
| familiar-brokenness 5 years in and take up little of your
| time, for most non-trendy platforms, but you're either
| using a trendy one that changes way too much, or will be on
| a different language + ecosystem entirely before you hit 5
| years on this one).
|
| Very little dev effort is working on anything cool, and
| very little of the code for cool projects isn't kinda
| boring and normal.
| delaynomore wrote:
| For a lot of developers, "brutally monotonous work" is just
| ... work.
| NAK21 wrote:
| Maybe I'm missing what's ancient about Fedora or RHEL, care
| to share?
| CoolGuySteve wrote:
| RHEL 7 came out 6 years ago with Linux 3.10 and is still
| getting patched. Somebody has to manage and integrate all
| those security fixes in all those packages without
| breaking the old codebases.
| chasil wrote:
| ...it's not just getting patched.
|
| Kernelcare has given me 48 hotfixes on a 3.10 kernel that
| I booted last year. kcarectl --patch-
| info | awk '/^kpatch-name/{print ++n};{print}'
| .... 48 kpatch-name: 3.10.0/proc-
| restrict-pagemap-access-1062.patch kpatch-
| description: Restrict access to
| pagemap/kpageflags/kpagecount kpatch-kernel:
| kpatch-cve: kpatch-cvss: kpatch-cve-
| url:
| http://googleprojectzero.blogspot.ru/2015/03/exploiting-
| dram-rowhammer-bug-to-gain.html kpatch-patch-url:
| uname: 3.10.0-1160.25.1.el7
| jaboutboul wrote:
| +1 for KernelCare.
| gnufx wrote:
| Actually, POWER9 RHEL7 has Linux 4.x, where x depends on
| the minor release -- unfortunately not the latest on the
| system I use. I think aarch64 is similar, but I'd have to
| look for rpm to check. They need similar attention, of
| course.
|
| Anyway, RHEL kernels have various features backported to
| the vanilla version on which it was originally based, not
| just security patches, which probably makes the job
| harder. It is a major effort.
| dralley wrote:
| The author seems to be complaining that instead of every distro
| having their own copy of specfiles, the specfiles are semi-
| shared and use conditional logic to include or exclude
| components depending on which distribution the package is being
| built for.
|
| In this particular case a feature should have been disabled on
| Fedora, but was enabled unconditionally, which caused problems
| on Fedora.
|
| They seem to be further complaining that when this bug was
| fixed [0], a condition was added for "fedora" rather than
| "rhel", meaning that any Fedora derivatives might trip over
| this issue (because they wouldn't trigger the condition).
|
| But they never made this complaint in the actual Bugzilla [0]
| where someone could consider their feedback, they skipped
| straight to the "complain via blog post" phase. Just like they
| did in their first blog post [1] where they said
|
| >I would file a bug report but I cannot imagine that Fedora
| would accept it. They already know that this feature doesn't
| work; it's right there in the DKMS manpage. It's there anyway
| because, well, I don't know. This is the most user-hostile
| decision I think I've ever seen Fedora make.
|
| Nevertheless it seems they did file the bug report, and it was
| accepted, and fixed in less than a week.
|
| My advice to the author is that perhaps they should extend a
| little more charity and "just ask" first, before they jump at
| the opportunity to complain in public - without having
| mentioned the issue to anyone with the ability to fix it.
|
| [0] https://bugzilla.redhat.com/show_bug.cgi?id=1962841
|
| [1]
| https://utcc.utoronto.ca/~cks/space/blog/linux/FedoraWeakUpd...
| kjs3 wrote:
| Welcome to the social media era. You don't get
| clicks/likes/upvotes by going through the process to engage
| with people, you get them by running to social media and
| making mountains out of molehills, for the lulz. Remember,
| it's not about community, or helping out, or just doing the
| right thing, it's about your "influencer" clout.
| 3v1n0 wrote:
| Also debian uses conditional rules on some packages whether
| something is for debian, ubuntu or a derivative
| DiabloD3 wrote:
| This is only in cases where the packages are maintained by
| a joint Debian/Ubuntu team, so everyone is already on board
| to make sure this works.
|
| Redhat, otoh, fosters a culture that does not care about
| Fedora.
| dralley wrote:
| > Redhat, otoh, fosters a culture that does not care
| about Fedora.
|
| disclaimer: I do work for Red Hat, my opinions are my
| own.
|
| Why do you feel that way?
| dralley wrote:
| Good point, I see someone posted an example downthread
|
| https://salsa.debian.org/search?search=Ubuntu&group_id=4586
| &...
| gnufx wrote:
| For what it's worth, some Fedora maintainers maintain that
| maintainers generally should use branches and not spec
| conditionals. Other maintainers ignore them. That's a branch
| for every Fedora and EL release (assuming you maintain for
| EPEL) and pending releases; I'd rather not.
|
| I see nothing wrong with that conditional. It's a toss up
| which way you write such things, sometimes trying to second-
| guess future EL versions. I'd expect any Fedora derivative to
| define %fedora, the way RHEL derivatives define %rhel as well
| as, say, %centos.
|
| Good advice to the author. Apart from anything else, bug
| reports can be useful to fellow users, even if maintainers
| don't make the requested change -- or perhaps don't until
| enough ire from other users accumulates under the report.
| [deleted]
___________________________________________________________________
(page generated 2021-06-03 23:01 UTC)