4 ms·

The problem is that, as a software developer, I am not going to learn 3 PMs to distribute my free software (yum, apt, homebrew) nor am I going to navigate the p

The problem is that, as a software developer, I am not going to learn 3 PMs to distribute my free software (yum, apt, homebrew) nor am I going to navigate the politics of Fedora, Debian, Ubuntu, etc. for getting my free software included in their repositories and/or keeping it current. I have things to do, like write software. Language PMs are "good enough" to solve the problems of the people actually writing the software, and in most cases that is really all that matters. I'm sorry they're not good enough for you, but it's not my fault that Rust, Python, and Go will let me upload to their package manager but Debian/Fedora/whatever you use will not. Your fight is not with the language PMs, it is with your OS vendor who will neither give me upload rights nor send out someone else who does, who neither designs tools for me to use nor sends someone who already knows how to use them. To be clear, I think there are good reasons why OS vendors won't change their ways, but software developers won't change our ways either, so neither language PMs nor OS PMs are going away any time soon.

ciupicri 11y ago
No one is stopping you from creating your own yum or apt repository. For Fedora you could use COPR [1]: > Copr is an easy-to-use automatic build system providing a package repository as its output. > Start with making your own repository in these three steps: 1) choose an architecture and system you want to build for; 2) provide Copr with src.rpm packages available online; 3) let Copr do all the work and wait for your new repo. [1]: https://copr.fedorainfracloud.org/ https://copr.fedorainfracloud.org/
- lbotos 11y ago
  You missed his point. As a software level developer if he uses "his language package manager" that's where his responsibility stops. In your example, he'd make a package for yum or apt but what about brew what about $obscure_other_one? It's an abstraction layer.
tadfisher 11y ago
The responsibility to package software at a system level isn't yours, it's the system vendor's. Let them hash out a standard packaging model while you ship your plain tarball or provide `configure && make && make install` instructions.
snuxoll 11y ago
> Your fight is not with the language PMs, it is with your OS vendor who will neither give me upload rights nor send out someone else who does, who neither designs tools for me to use nor sends someone who already knows how to use them. As far as Fedora is concerned becoming a package maintainer is a fairly straightforward process, and you are more than welcome to package up your own software and submit it to the software collection or solicit someone to assist you with it. The rpmdevtools package contains a super-useful utility called rpmdev-newspec that provides templates to create packages for most popular standards out there already (ruby gems, python setuptools/distutils scripts, CPAN modules, etc) - it's really easy to get started and you can always push your packages up to COPR without needing sponsorship from the existing packaging team.
- yxhuvud 11y ago
  This is missing the point. The problem is still that there is a million different system PMs, but (usually) only one for each language. The package maintainer have no incentive to care about Fedora, regardless of how easy it is. The real solution is not for Fedora to absorb all language specific packages but to integrate the different package managers so that they work better together.
  - snuxoll 11y ago
    > The real solution is not for Fedora to absorb all language specific packages but to integrate the different package managers so that they work better together. Which is precisely why rpmdev-newspec has templates for this case. Simply running rpmdev-newspec -t ruby/python/perl/php-pear/ocaml/R mypackagename will generate a rpmspec file ready to go for any of these languages using their standard package managers (gem, distutils/setuptools, CPAN, pear, OPAM, packrat) - just add necessary metadata (Requires/BuildRequires, summary, description, version, and a changelog). It's not magic, it still requires minimal effort (3 minutes worth of metadata + calling mock to test the build) - but it's hardly difficult. Sure, you could make some extra scripts to automatically populate the metadata from the language PM's descriptor of choice to limit the manual work to release bumps and editing the changelog - and I don't think anyone would be opposed to that, but that's pretty much all that would be left. The biggest problem is outside of rolling-release distributions like Arch, Gentoo, OpenSUSE Tumbleweed and Fedora Rawhide bumps in major versions within a release are highly discouraged - and a lot of people used to using language PM's have a habit of changing things rapidly even post-1.0 and not supporting old branches - often leaving the distribution packager with needing to backport patches for security or bug fixes. I'm not going to argue if it's better or worse, but it's an issue that needs to be addressed.
yxhuvud 11y ago
The ideal solution would be for the system PM to delegate the responsibility for the language dependencies to the language (preferably compartmentalized). It would be pretty slick to have a standardized way for language PMs to be able to declare dependencies on system packages.
emj 11y ago
What you say is very sane why should learn 3 packet managers. The problem is that language packet managers are not good enough, they are enough to get software to install on the developers system. Often leaves the future and the users hanging there with something less optimal. I guess my issue is that "good enough" is a very fluid concept, and I often discover some months after that it was my excuse for shitty code/integration test.

ciupicri 11y ago

No one is stopping you from creating your own yum or apt repository. For Fedora you could use COPR [1]: > Copr is an easy-to-use automatic build system providing a package repository as its output. > Start with making your own repository in these three steps: 1) choose an architecture and system you want to build for; 2) provide Copr with src.rpm packages available online; 3) let Copr do all the work and wait for your new repo. [1]: https://copr.fedorainfracloud.org/ https://copr.fedorainfracloud.org/

lbotos 11y ago
You missed his point. As a software level developer if he uses "his language package manager" that's where his responsibility stops. In your example, he'd make a package for yum or apt but what about brew what about $obscure_other_one? It's an abstraction layer.

tadfisher 11y ago

The responsibility to package software at a system level isn't yours, it's the system vendor's. Let them hash out a standard packaging model while you ship your plain tarball or provide `configure && make && make install` instructions.

snuxoll 11y ago

> Your fight is not with the language PMs, it is with your OS vendor who will neither give me upload rights nor send out someone else who does, who neither designs tools for me to use nor sends someone who already knows how to use them. As far as Fedora is concerned becoming a package maintainer is a fairly straightforward process, and you are more than welcome to package up your own software and submit it to the software collection or solicit someone to assist you with it. The rpmdevtools package contains a super-useful utility called rpmdev-newspec that provides templates to create packages for most popular standards out there already (ruby gems, python setuptools/distutils scripts, CPAN modules, etc) - it's really easy to get started and you can always push your packages up to COPR without needing sponsorship from the existing packaging team.

yxhuvud 11y ago
This is missing the point. The problem is still that there is a million different system PMs, but (usually) only one for each language. The package maintainer have no incentive to care about Fedora, regardless of how easy it is. The real solution is not for Fedora to absorb all language specific packages but to integrate the different package managers so that they work better together.
- snuxoll 11y ago
  > The real solution is not for Fedora to absorb all language specific packages but to integrate the different package managers so that they work better together. Which is precisely why rpmdev-newspec has templates for this case. Simply running rpmdev-newspec -t ruby/python/perl/php-pear/ocaml/R mypackagename will generate a rpmspec file ready to go for any of these languages using their standard package managers (gem, distutils/setuptools, CPAN, pear, OPAM, packrat) - just add necessary metadata (Requires/BuildRequires, summary, description, version, and a changelog). It's not magic, it still requires minimal effort (3 minutes worth of metadata + calling mock to test the build) - but it's hardly difficult. Sure, you could make some extra scripts to automatically populate the metadata from the language PM's descriptor of choice to limit the manual work to release bumps and editing the changelog - and I don't think anyone would be opposed to that, but that's pretty much all that would be left. The biggest problem is outside of rolling-release distributions like Arch, Gentoo, OpenSUSE Tumbleweed and Fedora Rawhide bumps in major versions within a release are highly discouraged - and a lot of people used to using language PM's have a habit of changing things rapidly even post-1.0 and not supporting old branches - often leaving the distribution packager with needing to backport patches for security or bug fixes. I'm not going to argue if it's better or worse, but it's an issue that needs to be addressed.

yxhuvud 11y ago

The ideal solution would be for the system PM to delegate the responsibility for the language dependencies to the language (preferably compartmentalized). It would be pretty slick to have a standardized way for language PMs to be able to declare dependencies on system packages.

emj 11y ago

What you say is very sane why should learn 3 packet managers. The problem is that language packet managers are not good enough, they are enough to get software to install on the developers system. Often leaves the future and the users hanging there with something less optimal. I guess my issue is that "good enough" is a very fluid concept, and I often discover some months after that it was my excuse for shitty code/integration test.