4 ms·

I'll match your bluntness, then: suggesting that anything on the order of 2 million packages are actually useful is plainly ridiculous. Debian et al act as qual

I'll match your bluntness, then: suggesting that anything on the order of 2 million packages are actually useful is plainly ridiculous. Debian et al act as quality filters by only actually packaging the stuff anyone cares about or needs. A stronger argument along these lines lists the packages that you actually need which are missing. And once you have such a list -- add them to Debian! It's not particularly difficult.

jacques_chester 4y ago
If only one in ten npm packages is useful, that's still 2x Debian's current current package count. I just don't think there are enough people available and willing to what you want. I would be happy to be proved wrong.
- ddevault 4y ago
  Far fewer than 1 in 10 npm packages is useful. I don't think you understand what I want. I don't want to see all of the packages in these repositories added to Linux distributions. I want to see the packages that you need added to these distros.
  - jacques_chester 4y ago
    > I want to see the packages that you need added to these distros. So if I need a package, and it's not in the curated repo, what do I do? And no, I don't want to maintain the curated version myself. The whole point of using someone else's software was to save time and effort.
    - ddevault 4y ago
      You add it. You are responsible for your dependencies. You should already be getting notified of new releases, reading changelogs, etc, and bumping the pkgver in some repository is not arduous on top of that. The labor, split among everyone who does this, is very managable.
      - jacques_chester 4y ago
        It won't happen. But please prove me wrong by finding thousands of people aching to curate tens of thousands of packages that are already widely available through well-known central repositories.
cortesoft 4y ago
And because Debian has such strict curation, a lot of software ends up being distributed via other channels, either from alternative deb package repos or not using a deb package at all. If we add a lot of curation, you will end up with a lot of gems being forced out of rubygems. This will make people become used to sourcing gems from alternative locations, and you will lose even the most basic of protection you get from what rubygems is doing. You, or anyone else, is welcome to create their own, curated and vetted, gem repository. It is not technically difficult to source gems from places other than rubygems, so if there was a demand, developers could use your curated service.
- ddevault 4y ago
  Debian's curation is not so strict as you suggest, and what's more: there are more distributions than just Debian. Add the packages you need and you'll be fine. I can speak from personal experience in this respect.
  - cortesoft 4y ago
    That’s my point. If you make it so people are required to go to other sources of packages for normal operations, then it normalizes untrusted distributors of packages.
    - ddevault 4y ago
      I don't understand how your response follows from the points I made. In any case, people who need a package should add it to their distributions. This is what we should normalize. Especially for users like developers who depend on software libraries, who already have the necessary skillset and motivation.
dalke 4y ago
I had code that was in Debian. https://tracker.debian.org/pkg/chemfp https://tracker.debian.org/pkg/chemfp . Someone else added it, so I guess they thought it was useful. I know someone who used it too. You can see it's version 1.1p1, which was a very old version. Here's 1.6 on PyPI - https://pypi.org/project/chemfp/ https://pypi.org/project/chemfp/ . When new releases came out - free software under the MIT license, available at no cost - I sent an email to the maintainers to let them know. I never got a response. It was never updated. Is my code useful? I think it's useful .. for the small niche I'm in. People do pay me for it. And there are a lot of niche packages. FWIW, I later switched to a commercial free software business model, where customers paid me for access to the source under the MIT license. More specifically, "we encourage people who redistribute free software to charge as much as they wish or can ... you might as well charge a substantial fee and make some money." https://www.gnu.org/philosophy/selling.en.html https://www.gnu.org/philosophy/selling.en.html I realize that I could maintain Debian packages myself. But while it's "not particularly difficult", it's still more than I want to do. FWIW, based on my download logs for July-to-date, I should start with Ubuntu: 2 Amazon Linux 2 CentOS Linux 3 Pop!_OS 5 Linux Mint 6 Raspbian GNU/Linux 12 Gentoo 19 Debian GNU/Linux 114 Ubuntu By comparison, it's even simpler to support all of these system via a pip-installable package.
- ddevault 4y ago
  This is a common error. In actuality, it's not your job to maintain your own software in Linux distributions. It's the job of users of each distribution to step up and maintain the software they need. https://drewdevault.com/2021/09/27/Let-distros-do-their-job.html https://drewdevault.com/2021/09/27/Let-distros-do-their-job....
  - dalke 4y ago
    You earlier wrote "Debian et al act as quality filters by only actually packaging the stuff anyone cares about or needs." I think you omitted the important qualifier "as long as there's someone willing to maintain the package." As I tried to demonstrate, there weren't enough people using my package on Debian to maintain it. I believe it's useful, so 1) why not, and 2) what should happen next? In that case, I expect most people will download and install the wheel/tarball from me. I distribute the most recent versions of chemfp from my own web site, not via PyPI. I have a URL structure following the Python Simple Repository API, which lets people 'pip install' it directly. This certain seems easier for any of my users than going through the extra steps of packaging it for Debian first, such that I don't see why they would do the extra work. (Or, with the source distribution, avoid pip and untar/cd/python setup.py install.) To be clear, it's not like you're wrong. Indeed, many people in my space use conda, a software distribution system which supports Linux, macOS and MS Windows, and allows multiple environments each with different sets of versions and dependencies. And conda supports channels, which allow oversight and review, eg, see Bioconda, at https://bioconda.github.io/contributor/index.html https://bioconda.github.io/contributor/index.html . I've been trying to understand what "Linux-style distribution" means. I think you mean third-party vetted package distribution, yes? Because otherwise "Linux-style" seems to cover a lot of variations, from Debian-style ones requiring a long-time vetting process to become a Debian Developer, to Bioconda (and nixpkgs?) where the vetting process seems easier - perhaps because Microsoft/GitHub help with the vetting? If so, wouldn't that "vetted software distribution" be a more clear phrase? (FWIW, my first package manager was 'inst' on IRIX, which could be used to install non-SGI contributed packages, so I think that's also a "Linux-style distribution", yes? Even though Linux didn't exist at that point.) But even then, these don't solve the problem of what to do if there isn't someone willing to maintain the package or worse, decides that package X shouldn't be supported/updated even though others find it useful. While unvetted systems don't have that gatekeeper problem.

jacques_chester 4y ago

If only one in ten npm packages is useful, that's still 2x Debian's current current package count. I just don't think there are enough people available and willing to what you want. I would be happy to be proved wrong.

ddevault 4y ago
Far fewer than 1 in 10 npm packages is useful. I don't think you understand what I want. I don't want to see all of the packages in these repositories added to Linux distributions. I want to see the packages that you need added to these distros.
- jacques_chester 4y ago
  > I want to see the packages that you need added to these distros. So if I need a package, and it's not in the curated repo, what do I do? And no, I don't want to maintain the curated version myself. The whole point of using someone else's software was to save time and effort.
  - ddevault 4y ago
    You add it. You are responsible for your dependencies. You should already be getting notified of new releases, reading changelogs, etc, and bumping the pkgver in some repository is not arduous on top of that. The labor, split among everyone who does this, is very managable.
    - jacques_chester 4y ago
      It won't happen. But please prove me wrong by finding thousands of people aching to curate tens of thousands of packages that are already widely available through well-known central repositories.

cortesoft 4y ago

And because Debian has such strict curation, a lot of software ends up being distributed via other channels, either from alternative deb package repos or not using a deb package at all. If we add a lot of curation, you will end up with a lot of gems being forced out of rubygems. This will make people become used to sourcing gems from alternative locations, and you will lose even the most basic of protection you get from what rubygems is doing. You, or anyone else, is welcome to create their own, curated and vetted, gem repository. It is not technically difficult to source gems from places other than rubygems, so if there was a demand, developers could use your curated service.

ddevault 4y ago
Debian's curation is not so strict as you suggest, and what's more: there are more distributions than just Debian. Add the packages you need and you'll be fine. I can speak from personal experience in this respect.
- cortesoft 4y ago
  That’s my point. If you make it so people are required to go to other sources of packages for normal operations, then it normalizes untrusted distributors of packages.
  - ddevault 4y ago
    I don't understand how your response follows from the points I made. In any case, people who need a package should add it to their distributions. This is what we should normalize. Especially for users like developers who depend on software libraries, who already have the necessary skillset and motivation.

dalke 4y ago

I had code that was in Debian. https://tracker.debian.org/pkg/chemfp https://tracker.debian.org/pkg/chemfp . Someone else added it, so I guess they thought it was useful. I know someone who used it too. You can see it's version 1.1p1, which was a very old version. Here's 1.6 on PyPI - https://pypi.org/project/chemfp/ https://pypi.org/project/chemfp/ . When new releases came out - free software under the MIT license, available at no cost - I sent an email to the maintainers to let them know. I never got a response. It was never updated. Is my code useful? I think it's useful .. for the small niche I'm in. People do pay me for it. And there are a lot of niche packages. FWIW, I later switched to a commercial free software business model, where customers paid me for access to the source under the MIT license. More specifically, "we encourage people who redistribute free software to charge as much as they wish or can ... you might as well charge a substantial fee and make some money." https://www.gnu.org/philosophy/selling.en.html https://www.gnu.org/philosophy/selling.en.html I realize that I could maintain Debian packages myself. But while it's "not particularly difficult", it's still more than I want to do. FWIW, based on my download logs for July-to-date, I should start with Ubuntu: 2 Amazon Linux 2 CentOS Linux 3 Pop!_OS 5 Linux Mint 6 Raspbian GNU/Linux 12 Gentoo 19 Debian GNU/Linux 114 Ubuntu By comparison, it's even simpler to support all of these system via a pip-installable package.

ddevault 4y ago
This is a common error. In actuality, it's not your job to maintain your own software in Linux distributions. It's the job of users of each distribution to step up and maintain the software they need. https://drewdevault.com/2021/09/27/Let-distros-do-their-job.html https://drewdevault.com/2021/09/27/Let-distros-do-their-job....
- dalke 4y ago
  You earlier wrote "Debian et al act as quality filters by only actually packaging the stuff anyone cares about or needs." I think you omitted the important qualifier "as long as there's someone willing to maintain the package." As I tried to demonstrate, there weren't enough people using my package on Debian to maintain it. I believe it's useful, so 1) why not, and 2) what should happen next? In that case, I expect most people will download and install the wheel/tarball from me. I distribute the most recent versions of chemfp from my own web site, not via PyPI. I have a URL structure following the Python Simple Repository API, which lets people 'pip install' it directly. This certain seems easier for any of my users than going through the extra steps of packaging it for Debian first, such that I don't see why they would do the extra work. (Or, with the source distribution, avoid pip and untar/cd/python setup.py install.) To be clear, it's not like you're wrong. Indeed, many people in my space use conda, a software distribution system which supports Linux, macOS and MS Windows, and allows multiple environments each with different sets of versions and dependencies. And conda supports channels, which allow oversight and review, eg, see Bioconda, at https://bioconda.github.io/contributor/index.html https://bioconda.github.io/contributor/index.html . I've been trying to understand what "Linux-style distribution" means. I think you mean third-party vetted package distribution, yes? Because otherwise "Linux-style" seems to cover a lot of variations, from Debian-style ones requiring a long-time vetting process to become a Debian Developer, to Bioconda (and nixpkgs?) where the vetting process seems easier - perhaps because Microsoft/GitHub help with the vetting? If so, wouldn't that "vetted software distribution" be a more clear phrase? (FWIW, my first package manager was 'inst' on IRIX, which could be used to install non-SGI contributed packages, so I think that's also a "Linux-style distribution", yes? Even though Linux didn't exist at that point.) But even then, these don't solve the problem of what to do if there isn't someone willing to maintain the package or worse, decides that package X shouldn't be supported/updated even though others find it useful. While unvetted systems don't have that gatekeeper problem.