On Tue, 7 Jan 2020 at 13:28, Neal Gompa <ngomp...@gmail.com> wrote: > > On Tue, Jan 7, 2020 at 7:04 AM Martin Kolman <mkol...@redhat.com> wrote: > > > > On Tue, 2020-01-07 at 10:36 +0100, Vít Ondruch wrote: > > > Dne 06. 01. 20 v 19:08 Nicolas Mailhot via devel napsal(a): > > > > Le 2020-01-06 19:05, Nicolas Mailhot a écrit : > > > > > > > > > Handling those checks is where the packaging toil is (that is, as long > > > > > as Fedora is a deployment project). It is not something the packaging > > > > > format makes harder. > > > > > > > > However, because our packaging format streamlines those checks, and > > > > forces to apply them, it is blamed by devs for the impedance mismatch > > > > between dev and deployment requirements. > > > > > > > > But, this mismatch is not caused by our packaging format. It is caused > > > > by devs taking shortcuts because their language packaging format lets > > > > them. > > > > > > > > > > Well said Nicolas. > > > > > > Embracing the "language-native packaging" and "git repos" is giving up > > > on what Fedora maintainers have always did and that is kicking forward > > > all the upstreams, because we force them to keep updating the > > > dependencies (or to maintain compatibility with old versions of > > > dependencies). Once we embrace "git repos" etc, we will lose our soul > > > IMO. There won't be any collaboration between upstream projects, which > > > was cultivated by distribution maintainers. Upstreams will sit in their > > > silos and bundle everything. > > Just recently I've read a discussion (IIRC on Hacker News) about an article > > about yet another mess due to NPM (I think this was for a change some > > licensing mess, > > not another malware) where someone suggested a radical new idea: "Lets have > > a > > crowd sourced set of packages that are known to have sane licenses, don't > > contain > > malware/CVEs and can work together!". Yeah, like, say a Linux distro such > > as Fedora ? > > > > Basically, it seems to me that the language specific package management > > systems > > are already creaking under load & display critical issues almost on a daily > > basis. > > Issues people with distro packaging background pointed out long ago, only > > to be ignored. > > > > So I think it really makes much more sense to continue with all the nice > > nice improvements > > we have been doing in RPM packaging, rather than throwing it all away and > > switching to > > a fundamentally inferior technology. > > > > > > > > Also, just today I had discussion if Ruby packages should be more Fedora > > > tailored or more upstream like and there is no right way which could > > > reasonably satisfy both worlds. > > > > > > E.g. if upstream package has Windows specific dependencies, it is kind > > > of natural to strip this dependency on Fedora. OTOH, it possibly breaks > > > a dependency resolving on other platforms, if the project was created > > > using Fedora packages. This is unfortunately the reason for devs to take > > > some shortcut, probably to go with upstream way, because if nothing > > > else, it is typically better documented. > > > > > There's some interesting cognitive dissonance here. In HN threads > where I've seen this, people seem to be naturally discovering that > what they want is a curation point for these modules, but when someone > points out that the Linux distribution essentially functions in that > role, there's some recoil. They say that they don't want that.
Language-specific packaging formats share a common thing: they are designed to be installed in the users' home, or equivalently, in a virtual environment without root permissions. I'm guessing here, but the recoil you reference probably comes from the fact that distro-wide packaging systems require admin privileges. If that's true, then I think we should further promote Fedora toolbox. Iñaki > I think the underlying problem here is that we don't sell ourselves > well in the value proposition to these people. Most people sadly > reference Debian as their idea of a Linux distribution. While they > certainly provide certainty and curation, they are often too slow to > be usable by developers to leverage new features and capabilities for > their software. This is something we need to figure out how to market > better for Fedora desktop, server, and cloud variants. We provide much > of the same benefits that Debian does, except we also provide fresher > stacks and new features more quickly for people to leverage. > > "Friends. Features. Freedom. First. Fedora" > > > > -- > 真実はいつも一つ！/ Always, there's only one truth! > _______________________________________________ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > 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@lists.fedoraproject.org -- Iñaki Úcar On Tue, 7 Jan 2020 at 13:28, Neal Gompa <ngomp...@gmail.com> wrote: > > On Tue, Jan 7, 2020 at 7:04 AM Martin Kolman <mkol...@redhat.com> wrote: > > > > On Tue, 2020-01-07 at 10:36 +0100, Vít Ondruch wrote: > > > Dne 06. 01. 20 v 19:08 Nicolas Mailhot via devel napsal(a): > > > > Le 2020-01-06 19:05, Nicolas Mailhot a écrit : > > > > > > > > > Handling those checks is where the packaging toil is (that is, as long > > > > > as Fedora is a deployment project). It is not something the packaging > > > > > format makes harder. > > > > > > > > However, because our packaging format streamlines those checks, and > > > > forces to apply them, it is blamed by devs for the impedance mismatch > > > > between dev and deployment requirements. > > > > > > > > But, this mismatch is not caused by our packaging format. It is caused > > > > by devs taking shortcuts because their language packaging format lets > > > > them. > > > > > > > > > > Well said Nicolas. > > > > > > Embracing the "language-native packaging" and "git repos" is giving up > > > on what Fedora maintainers have always did and that is kicking forward > > > all the upstreams, because we force them to keep updating the > > > dependencies (or to maintain compatibility with old versions of > > > dependencies). Once we embrace "git repos" etc, we will lose our soul > > > IMO. There won't be any collaboration between upstream projects, which > > > was cultivated by distribution maintainers. Upstreams will sit in their > > > silos and bundle everything. > > Just recently I've read a discussion (IIRC on Hacker News) about an article > > about yet another mess due to NPM (I think this was for a change some > > licensing mess, > > not another malware) where someone suggested a radical new idea: "Lets have > > a > > crowd sourced set of packages that are known to have sane licenses, don't > > contain > > malware/CVEs and can work together!". Yeah, like, say a Linux distro such > > as Fedora ? > > > > Basically, it seems to me that the language specific package management > > systems > > are already creaking under load & display critical issues almost on a daily > > basis. > > Issues people with distro packaging background pointed out long ago, only > > to be ignored. > > > > So I think it really makes much more sense to continue with all the nice > > nice improvements > > we have been doing in RPM packaging, rather than throwing it all away and > > switching to > > a fundamentally inferior technology. > > > > > > > > Also, just today I had discussion if Ruby packages should be more Fedora > > > tailored or more upstream like and there is no right way which could > > > reasonably satisfy both worlds. > > > > > > E.g. if upstream package has Windows specific dependencies, it is kind > > > of natural to strip this dependency on Fedora. OTOH, it possibly breaks > > > a dependency resolving on other platforms, if the project was created > > > using Fedora packages. This is unfortunately the reason for devs to take > > > some shortcut, probably to go with upstream way, because if nothing > > > else, it is typically better documented. > > > > > There's some interesting cognitive dissonance here. In HN threads > where I've seen this, people seem to be naturally discovering that > what they want is a curation point for these modules, but when someone > points out that the Linux distribution essentially functions in that > role, there's some recoil. They say that they don't want that. > > I think the underlying problem here is that we don't sell ourselves > well in the value proposition to these people. Most people sadly > reference Debian as their idea of a Linux distribution. While they > certainly provide certainty and curation, they are often too slow to > be usable by developers to leverage new features and capabilities for > their software. This is something we need to figure out how to market > better for Fedora desktop, server, and cloud variants. We provide much > of the same benefits that Debian does, except we also provide fresher > stacks and new features more quickly for people to leverage. > > "Friends. Features. Freedom. First. Fedora" > > > > -- > 真実はいつも一つ！/ Always, there's only one truth! > _______________________________________________ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > 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@lists.fedoraproject.org -- Iñaki Úcar _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
