On Thu, 4 Apr 2024 at 12:21, Arnie T via devel <devel@xxxxxxxxxxxxxxxxxxxxxxx> wrote:
Hello Stephen,How a decision to drop xz for some other compression library for software would be a fairly slow process. First a person who is willing to do the work would come up with a proposal on why it should be done and how it could be done. They would be expected to also test to see how much trouble this would be (aka find all the packages which use xz and could be changed to another library, which ones couldn't and what the effects would be.) Once that is done, they would make a general proposal to be reviewed by whatever technical committee a distribution has (Fedora has one whose acronym is FESCO, Debian has another or multiple others, etc). This would be reviewed and if accepted it would go as a future release work with a staged plan where some packages are moved in X release, some in X+1, and some final plan for X+2 (or backed out completely for some reason before then). There would be some amount of software which would rely on xz no matter what because either the upstream has no interest in changing or it is meant to use xz period....Currently most groups are between 0 and 1. There are a lot of things which need to be looked at before moving off can be looked at as a goal to make sure we aren't making things worse.I hope the above helpsThanks, I understand more of your explanation of how it's done.I don't know how much time was needed to decide for example an Arch Distro change"Now using Zstandard instead of xz for package compression"
So that is an individual package choice a distribution maintainer(s) can make. In this case the pacman maintainers decided to use a different library for their packages. It doesn't change anything outside of that one tool though. It is also not getting rid of xz from Arch. They will need to keep xz around because older systems will have used the older compression and pacman and similar tools will need to 'read' that. It mainly means that newer packages will use zstandard versus xz.
A similar change in Fedora would be that rpm uses zstandard by default etc. However rpm would need to keep xz because of 10 years of using xz as a compression standard in various RPMs and people need to install older software.
OK, that's my mistake. I thought that moving to open source Linux OS Distro like Redhat-related Fedora would result big or important issues can be fixed more efficiently than at Microsoft.
Decisions are people issues and people issues move at people speeds. There are about 1600 packagers in Fedora and I think 22,000 packages. Changes take time to communicate, understand and implement. The worst thing to do in a security situation is actually move too fast because you think you are getting ahead of the attacker. I have seen too many times where the attacker was waiting for said move and it makes their life easier. In this case, a bit of time is needed to really get an idea of what else is screwed up and where we need to fix things.
I guess I'm learning that even important or wise choices (not saying _this_ is) can't be done with taking a long time. Even if they are security related issues.Thanks one more time for the nice explanation!Cheers!Arnie--
_______________________________________________
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
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Stephen Smoogen, Red Hat Automotive
Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren-- _______________________________________________ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
