Dne 07. 01. 20 v 14:57 Iñaki Ucar napsal(a): > On Tue, 7 Jan 2020 at 13:28, Neal Gompa <ngompa13@xxxxxxxxx> wrote: >> On Tue, Jan 7, 2020 at 7:04 AM Martin Kolman <mkolman@xxxxxxxxxx> 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 Definitely not this one unfortunately. Vít > , 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@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 > > _______________________________________________ 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
