LWN: Comments on "Changing CentOS in mid-stream"

Changing CentOS in mid-stream

mathstuf — Fri, 05 Feb 2021 14:29:14 +0000

Well, NIST 800 is making FIPS an easy go-to for checkbox compliance. And a SCIF could be had at companies of all sizes; it really depends on the projects and data they're working on.

Changing CentOS in mid-stream

Cyberax — Fri, 05 Feb 2021 06:35:30 +0000

To be fair, if you care about FIPS and have a SCIF, you probably can pay for RHEL licenses out of your paperclip budget.

Changing CentOS in mid-stream

mathstuf — Thu, 04 Feb 2021 20:33:28 +0000

Note that Red Hat also gets packages certified for use by FIPS and for within SCIF infrastructure ("secure rooms"). For these cases, it is many times a *specific build* that is certified; a rebuild is *not* certified (I don't think Reproducible Builds factors into it; that may be considered sufficient for most, but these checkbox security things tend not to care about the bits as much as the color of the bits[1]).

[1]https://ansuz.sooke.bc.ca/entry/23

Changing CentOS in mid-stream

pizza — Thu, 04 Feb 2021 14:28:18 +0000

> Kernel, filesystem, packages are all created and maintained by upstream.

This is _not_ the case for RHEL (and its derivatives..)

Red Hat packages everything shipped in RHEL, and shoulders all of the maintenance work.

Upstreams only tend to care about RHEL (and backporting fixes to decade-old releases) when Red Hat is paying their salaries. (which, to be fair, they do quite a lot of!)

Changing CentOS in mid-stream

emailstorbala — Thu, 04 Feb 2021 14:17:53 +0000

Redhat users pays for the support. The product is an open source and hence it is rebranded as Centos (so is Oracle Linux and Scientific Linux). Kernel, filessystem, packages are all created and maintained by upstream.

So technically a customer who has paid money is paying for an issue case support and not for the RHEL itself. And support types differ and it payment also differs.

Changing CentOS in mid-stream

anselm — Wed, 30 Dec 2020 18:23:14 +0000

RPM packages are basically cpio archives with a header attached in front. There's an rpm2cpio program that will remove the header so the rest can be fed to cpio.

Changing CentOS in mid-stream

jwilk — Tue, 29 Dec 2020 16:06:00 +0000

> A Debian package can be stripped apart using cpio and tar

It's ar, not cpio: https://manpages.debian.org/deb.5

Changing CentOS in mid-stream

Wol — Sun, 27 Dec 2020 01:16:59 +0000

Just checked, I AM right.

Comply with (a) OR (b) OR (c) OR (d) OR (e).

Your choice - if you want to ignore 6(b) that's perfectly fine so long as you comply with one of the others.

Sheesh - talk about people not being able to understand plain simple English ... (or American :-)

Cheers,
Wol

Changing CentOS in mid-stream

Wol — Sun, 27 Dec 2020 01:13:55 +0000

Just a quick response, I haven't checked, but I'm pretty damn certain that 6(b) is an ALTERNATIVE clause. If you comply with 6(a) (or 6(c), (d) etc if they exist), then there is NO requirement to comply with 6(b).

In other words, you must comply with clause 6, but you can choose between (a) or (b) (or (c) or (d) or whatever).

Cheers,
Wol

Changing CentOS in mid-stream

imgx64 — Sat, 26 Dec 2020 04:10:48 +0000

I read the CentOS Stream FAQ:

What happens when CentOS Stream switches from RHEL 8 to RHEL 9 based content?
Around the time the RHEL 9 Public Beta is issued, an additional set of CentOS Stream repositories and ISOs will be available. The existing CentOS Stream repositories representing RHEL 8 bits will continue to be available, and changes to these bits will continue as before for the duration of the RHEL 8 Full Support Phase. At that time, the older repositories will be discontinued, although sources will continue to be available.

and it doesn't mention "a year after 9 is released". I think "repositories representing RHEL 8 bits" means binary yum repositories, not source git repositories, so you can keep using CentOS Stream 8 as long as RHEL 8 is supported. However, I'm not sure what are the older repositories that are being discontinued

Changing CentOS in mid-stream

jospoortvliet — Fri, 25 Dec 2020 22:31:54 +0000

Centos users aren't customers. Customers are people that pay you money for the work you do for them. Those customers were perhaps asking red hat why their competitors got access to the same software workout paying for it, gaining an advantage. That isn't something you want your customers to ask.

Changing CentOS in mid-stream

sfeam — Fri, 25 Dec 2020 20:01:24 +0000

Yet another example of how GPL3 is unusable in practice. Talks about overreaching!

Changing CentOS in mid-stream

sammythesnake — Fri, 25 Dec 2020 19:12:24 +0000

The GPL v3 requires "a written offer, valid for at least three years..." (section 6b) to provide the source, so they can't shut down the server within at least that period unless they want to offer CDs or the like as an alternative

Three years might be an interminable age or a blink of the eye depending on the circumstances, though.

The island of RPM

smoogen — Sat, 19 Dec 2020 19:32:00 +0000

I expect the correct phrase is:

The island of RPM is steadily shrinking will eventually sink beneath the ways of deb.

apt is equivalent to yum/dnf not to RPM.

Changing CentOS in mid-stream

Wol — Fri, 18 Dec 2020 22:53:09 +0000

> a couple of months later is Red Hat and SUSE is an independent entity out of Jurix.

If I remember my SuSE history correctly, it started a few months before Red Hat as a Slackware derivative. Then they rebased it on Jurix, before starting to use rpm as their packaging solution.

Cheers,
Wol

Changing CentOS in mid-stream

Cyberax — Fri, 18 Dec 2020 19:54:02 +0000

> Just yesterday I needed to know what had installed the file /etc/OpenCL/vendors/mesa.icd
You can use "apt-file search /etc/OpenCL/vendors/mesa.icd". It optionally can search for it in the remote repositories.

Changing CentOS in mid-stream

rahulsundaram — Fri, 18 Dec 2020 18:29:08 +0000

> Only really that I knew that Yum concept basically came from outside Red Hat - Yellow Dog Linux, then - and is alien to fundamental RPM - it's an add on

To be more accurate, YUP is from Yellow Dog. Yum although it shares some history with YUP is significantly different and originated from Duke university with Seth Vidal as the primary developer. Technically, similar to dpkg vs Apt. As you noted, just a higher level tool - I consider this as a package manager vs higher level dependency resolver (in Dnf - there are multiple libraries that handle different aspects and the resolver logic is part of libsolv - Originating from Opensuse). In Debian, there have been different resolvers in the past (Smart for example - Canonical at one point was considering making it the default resolver for Ubuntu).

Changing CentOS in mid-stream

farnz — Fri, 18 Dec 2020 17:57:41 +0000

But the VCS is also a general purpose tool, like a monitor, and when it comes to modifying code (e.g. to add support for a new printer type), I have no interest in what's in the VCS, whereas I do have a deep interest in having decent tools for actually making my changes. Indeed, if you give me the choice between my current monitor and a distribution tarball of the code, or a monitor half the area (a 22" or so) and full VCS history for a project I want to modify, I'll take the tarball and my current monitor every single time.

While I don't work at Red Hat, I suspect the same is true of their engineers too - full VCS history is nice, but good tools are far more important if you're modifying the code.

Changing CentOS in mid-stream

paulj — Fri, 18 Dec 2020 17:38:35 +0000

The preferences of the distributor are more germane to the point, particularly where the distributor seeks to deny the same to others.

If monitors were specific to software source code, and you needed a very specific monitor unique to a code-base in order to modify it, and it was typical in software for proprietary vendors of code-base to sell such monitors along with source-code; and if someone created a copyleft licence that required all the tools to be passed along to those the redistributed the code to; then yes... maybe you could require people to supply monitors.

However, in this world, the hardware is usually general, and the general hardware is usually not supplied. So, that's a super-hypothetical world.

The GPLv3 does require the tools - other than general-purpose - to be supplied as part of the source code.

Changing CentOS in mid-stream

amacater — Fri, 18 Dec 2020 17:14:20 +0000

Only really that I knew that Yum concept basically came from outside Red Hat - Yellow Dog Linux, then - and is alien to fundamental RPM - it's an add on.. I was trying to demonstrate the difference between fancy front ends and the most fundamental package ordering/dependency resolving "thing" - dpkg for Debian and RPM for Red Hat and derived distributions. (And yes, RPM has had a couple more rewrites and a change to lower case: dpkg was rewritten a few times in 1994 but is essentially the same since then).

There's not a lot to choose between them, as I wrote: I've had someone complain at me that it was harder to check signatures of packages in Debian because Debian signs the package manifest - but, meh, apt[-get|itude] checks that for you automatically and will whinge at you if the package list is out of date.

Changing CentOS in mid-stream

rahulsundaram — Fri, 18 Dec 2020 16:23:27 +0000

> Many Red Hat users have got used to using dnf/yum - in the case of yum, that's a third party contribution to Red Hat.

That's an odd way to phrase it given that it wasn't a contribution to the company as such, just happens to be an open source project not originating from any particular vendor like the vast majority of the distribution and I am not sure why it is relevant.

In any case, for the record, Seth Vidal who was the primary developer of Yum (and a key contributor to CentOS for that matter) and was an active direct contributor to Fedora during the time that Yum became default in Fedora (and subsequently RHEL, derived from Fedora adopted it) and was an employee of Red Hat for several years while working on Yum among other things till he passed away.

Some more backstory: https://www.linuxfoundation.org/blog/2013/07/in-memoriam-...

Changing CentOS in mid-stream

farnz — Fri, 18 Dec 2020 15:40:37 +0000

And, as an aside while you're thinking about where stretching this goes, my preferred form for modification of code is downloaded to the filesystem of a fast machine with a decent 32" monitor attached and an editor set up to my preferences. I use that for every modification I make, including the ones I have that are in the upstream Linux kernel.

A VCS is entirely optional for modifying code, given a decent editor with good undo facilities and auto-commenting of lines. It makes it much, much easier to share my modifications with people, and to track what is the code I got from upstream versus what I've modified, but I do not use the VCS as part of actually modifying the code. In contrast, I do use the fast computer, the editor, and the monitor as part of actually modifying code - I've never made a kernel modification without a monitor and an editor of my choice.

Changing CentOS in mid-stream

amacater — Fri, 18 Dec 2020 15:35:26 +0000

If apt doesn't do it, apt-file certainly does.

Many Red Hat users have got used to using dnf/yum - in the case of yum, that's a third party contribution to Red Hat.

dpkg -S queries at the same level as a raw rpm command

apt will do much of what you want. In some circumstances, you might want apt-file. apt-cache search foo is also useful and apt-cache is included in apt. [First came deity, then apt-get, then aptitude with a superior solver for package dependencies, then apt - the name goes back to Wed, 4 Mar 1998 19:58:33 +0000 (GMT) and the corresponding post on the debian-devel-mailing list - https://lists.debian.org/debian-devel/1998/03/msg00332.html ]

[For the curious, there was apparently a point at which Red Hat considered adopting something other than RPM right back at the beginning. Of the surviving distributions: Slackware is first, a few months later is Debian, a couple of months later is Red Hat and SUSE is an independent entity out of Jurix. And, for the purists: Debian packaging and Red Hat packaging are largely equivalent when all's said and done. A Debian package can be stripped apart using cpio and tar - an rpm requires a specific binary to do this if I remember rightly.]

Changing CentOS in mid-stream

rahulsundaram — Fri, 18 Dec 2020 15:15:21 +0000

> I don't think "apt" or "dnf" handles that at all.

This isn't true for dnf. yum/dnf has whatprovides and if you don't have the package installed and want to query against the repository metadata, you can use dnf repoquery (with yum, repoquery was a separate tool shipped as part of yum-utils).

Changing CentOS in mid-stream

zlynx — Fri, 18 Dec 2020 14:54:52 +0000

What, really?

Just yesterday I needed to know what had installed the file /etc/OpenCL/vendors/mesa.icd

The command to find that on Ubuntu is "dpkg -S /etc/OpenCL/vendors/mesa.icd". On Fedora it is "rpm -qf /etc/OpenCL/vendors/mesa.icd"

I don't think "apt" or "dnf" handles that at all.

There are actually a lot of things the higher level apt or dnf commands don't do.

Changing CentOS in mid-stream

farnz — Fri, 18 Dec 2020 13:21:09 +0000

But I use such a system, not to track the code, but to allow multiple people to work together on the code without conflicting. The VCS is a side-effect of that, used while I'm producing the work to allow several modifications to happen in parallel while providing me with a way to integrate them together into a final form that I release to my customers.

FWIW, when I worked somewhere that *did* distribute other people's copyleft software, every lawyer we dealt with said that the maximum the licence demanded was a tarball from my upstream, and a diff that could be applied with my changes to get to the modified version we shipped.

So, you can dance on pins trying to stretch the licence to require my development workflow to be shipped with my modified code, or you can stay clearly within the licence.

Changing CentOS in mid-stream

paulj — Fri, 18 Dec 2020 12:53:21 +0000

Well, I don't know where the line is. I think an argument can be made that, if the distributor has gone to trouble of implementing a system to keep track of the upstream source and each change made to it, and that system is well capable of exporting that information (while stripping non-code stuff, like customer/ticket meta-data), then that might be the more preferred form. Certainly, if that distributor further goes to extra effort to /remove/ that information...

Flip it around: Say you're a distributor of other people's copyleft software. You have a git tree tracking changes.

Do you want to try dance on pins to argue that the workflow that is the easiest (and practical - given scaling) for you, is somehow not preferable for others, and acceptable within the licence, trying to justify nformation-striping you added to frustrate competitors?

Or do you just export that git tree (with whatever git filter), to make sure you accommodate others, and err on the side of staying clearly within the licence?

Changing CentOS in mid-stream

farnz — Fri, 18 Dec 2020 12:16:32 +0000

And note that the ideal form for identifying their bug so I can fix it is not just the full revision history, but also full access to all the people involved in writing the changes so that I can talk to them about what they did, why they did it, and what the interactions with other changes are.

Taking your interpretation at face value, I could argue that because that's my preferred form of the code for fixing bugs, I have a right to your time if you distribute code to me (directly or indirectly). The GPL limits it to my preferred form for making modifications, and when I'm modifying code, I do that via a working copy and an editor, not via a VCS of some form.

Changing CentOS in mid-stream

farnz — Fri, 18 Dec 2020 11:45:13 +0000

If I am modifying the code, then I want the code as a whole on my filesystem - the output of `tar x` or similar. Revision control history is not something I need or usually want to make modifications to code.

You changed from making modifications to finding bugs introduced by modifications that my upstream made. In that situation, I'd like revision control history, as part of identifying the bug, not as part of modifying the code. Once I've identified the bug, I'll go back to the final form I was given and fix that.

Changing CentOS in mid-stream

paulj — Fri, 18 Dec 2020 11:39:49 +0000

I havn't changed anything. I've asked a question.

The GPL defines source code as "preferred form for modifications" - deliberately framed that way to remain general and be apply across technologies, and across time as tools and preferences change.

Asking questions about how developers work today, what they prefer to have in doing that work - within the confines of what the distributor has available - seems the correct way to me to figure out what "preferred form" should mean.

Changing CentOS in mid-stream

farnz — Fri, 18 Dec 2020 11:34:47 +0000

Now you've changed from what the GPL requires - it does not require the upstream to make it easy for me to identify which change is problematic, only that I can identify changes from the version my upstream received, and modify it.

If I want to fix-forward, then the version with stock kernel and all their changes is just fine - I don't need to know which change is problematic, I need to know what the bug is and fix it there. I only need to identify the problem change if I simply want to undo some of my upstream's changes but not all of them, and the GPL does not require upstream to make it easy for me to do that, as long as I can comfortably edit and rebuild the work as I received it.

Changing CentOS in mid-stream

farnz — Fri, 18 Dec 2020 11:29:30 +0000

The `make dist` tarballs. That gets me something that's close to what I'm actually using to start from, and has handled a lot of the details of whatever build system the project uses already - so there's less work for me in getting to the point where I can build their code and run with it.

This changes if I want to contribute the fix back, but it's the desire to contribute that pushes me to the extra hassle of the git tree, not details of how I'd fix the problem.

Changing CentOS in mid-stream

paulj — Fri, 18 Dec 2020 11:28:22 +0000

Now, say this Free Software is a kernel from a vendor. They have a git repo, with all the changes as commits; and they have another file that has the stock kernel source, and all their changes munged into one patch.

You want to figure out which of their changes from stock is the problem. You might want to bisect through all the changes, to find the problem change, so you can fix it.

Which form would you prefer to start with?

Changing CentOS in mid-stream

paulj — Fri, 18 Dec 2020 11:23:44 +0000

The GPL requires the "preferred form of the work for making modifications to it".

You're hitting a bug in some Free Software you're using, and you want to fix it. You go to the project's website. They have 'make dist' tarballs, and they have a git repository.

Which will you prefer to download, to make your modifications?

Changing CentOS in mid-stream

farnz — Fri, 18 Dec 2020 10:44:35 +0000

I'm not sure I agree with you, in the context of what the GPL is intended to enable.

While you would prefer the full revision history if you're trying to unpick why the distro did something, that's not something the GPL requires - only identification of the changes, and the ability for a recipient to make further changes. One big patch meets both of those requirements; you can clearly see what Red Hat got from upstream, and what changes Red Hat applied, and you can make further changes yourself.

Changing CentOS in mid-stream

mpr22 — Fri, 18 Dec 2020 02:12:56 +0000

The ones you are likely to need (and their man pages) are all part of package "apt", which is Essential: yes (i.e. all users and packagers are allowed to assume it is present on a "normal" Debian system", so

apropos 'apt(-.*|)\>'

should do the trick.

Don't bother with the APT User Guide in package "apt-doc", though. As far as I can tell, it's desperately undermaintained.

Changing CentOS in mid-stream

daniel — Fri, 18 Dec 2020 01:59:14 +0000

Why do people keep saying this is IBM's influence? Seems like classic Redhat to me.

Changing CentOS in mid-stream

rahulsundaram — Fri, 18 Dec 2020 01:42:19 +0000

>And then that bug-fixed version of the license will get rejected by those >intentionally taking advantage of the gray areas in the old license

...Which is fine. Arguably this already happened with GPLv2 and GPLv3. The old and new versions have clear delineations and the choices are transparent to everyone as opposed to talking about the nebulous spirit of the license which really can mean anything from "The author of the license thinks this way" to "the project using the license thinks it should be interpreted this way" to "this person in LWN who is connected to neither wishes the license has this expanded interpretation although the plain reading of the license doesn't really say that". It is not the job of a software license to mandate healthy best practices around a community. If that was the case, even GNU wouldn't past that test given that bash git changelog has a lot of tarballs checked in directly on a routine basis.

Changing CentOS in mid-stream

Cyberax — Fri, 18 Dec 2020 01:42:17 +0000

> As an outsider, every time I interact with the apt suite of tools I find myself confused and searching the Internet because I can't remember which tool I need to install to answer my query or even ask a simple `--help` about.
There's one tool you need to know: apt (and apt-file). It can do everything.

There's no need for dpkg shenanigans.

Changing CentOS in mid-stream

Wol — Fri, 18 Dec 2020 01:17:41 +0000

> Who is going to determine what the "spirit" of the license is and how is that going to be enforced?

The musings/writings of (people within) the FSF is a good determinant of the GPL. If the wording of a licence is not clear a Judge has two options - to interpret it in favour of the defendant(s), or to interpret it in the light of explanatory text by the authors. Both are valid approaches.

And I think, in UK courts, Judges have been known to read Hansard and use the contents thereof to ignore the explicit black letter of the law on the basis that "MPs were misled when asked to vote on it".

Cheers,
Wol