4 ms·

Using lock files is a good way to make sure your software never ends up in a distribution and in the hands of users.

MrJohz 4y ago
The popular Rust tool "ripgrep" uses a lock file for development (you can see it in the GitHub repo), and yet is in the official repositories for homebrew, various Windows package managers, Arch, Gentoo, Fedora, some versions of openSUSE, Guix, recent versions of Debian (and therefore Ubuntu), FreeBSD, OpenBSD, NetBSD, and Haiku. With all due respect, I don't think you're correct.
- bombolo 4y ago
  And how much rust software is packaged in distributions? Almost none. They haven't figured out the procedures, because distributions really really don't want pinned stuff around. Homebrew, windows, arch all have very very relaxed processes to enter. There is no QA, you can just do whatever you want. I mean more like Fedora and Debian.
  - dontlaugh 4y ago
    The distros will eventually stop this dangerous practice of mixing and matching versions for all dependencies. It can only work for a small set of system components, which is what every other OS does.
    - bombolo 4y ago
      It's more dangerous to let people pin dependencies and have vulnerable libraries in use forever.
      - burntsushi 4y ago
        Who says the distros are using the lock file? AFAIK, Debian doesn't use ripgrep's lock file, for example. They don't have to, because of semver.
        LtWorf 4y ago
        What's the point of the lockfile then?
        burntsushi 4y ago
        For people that want to build with the exact set of dependency versions tested by upstream. Just because some distros don't use them doesn't mean there isn't any point.
  - burntsushi 4y ago
    Bottom line is that the lock file in ripgrep's repo hasn't prevented it from being packaged. And I haven't heard of any distro maintainer complain about any lock file in any Rust program ever. So you're just plain empirically wrong about lock files preventing Rust programs from being packaged. You've now moved on to talking about something else, which is "how much Rust software is packaged." Well, apparently enough that Debian has Rust packaging policy[1]. I'll give you one guess at what isn't mentioned in that policy. Give up? Lock files! [1]: https://wiki.debian.org/Teams/RustPackaging/Policy https://wiki.debian.org/Teams/RustPackaging/Policy
    - bombolo 4y ago
      > So you're just plain empirically wrong about lock files preventing Rust programs from being packaged. My mistake, seems rust packagers gave up on decent packaging. It isn't so for the python policy, I can assure you :)
      - burntsushi 4y ago
        I haven't heard anyone complain about how Rust programs are packaged. Take your passive aggressive bullshit somewhere else.
        sseagull 4y ago
        How Linux package managers handle these newer languages with their own package managers (including rust) is an ongoing pain point. Here’s an article from 2017 about it, and I don’t know if things have improved: https://lwn.net/Articles/712318/ https://lwn.net/Articles/712318/
        burntsushi 4y ago
        I didn't say it wasn't a pain point or that there weren't challenges. I said I don't hear about people complain about how Rust programs are packaged. Not that the packaging of Rust programs (among others) itself doesn't present interesting challenges depending on the policies of a particular distro. Archlinux, for example, has far fewer problems than Debian because of differences in policy. The poster I was responding to was literally posting false information. I'm correcting it. This doesn't need to turn into a huge long sprawling discussion about packaging Rust programs. The main point that I was making is that lock files do not prevent Rust programs from being packaged. bombolo then went off on their own little tangents spouting nonsense without bothering to acknowledge their mistake.
throwawaaarrgh 4y ago
Distros can keep their own lock file that is based on their own release branch's versions. If it doesn't build, the pkg maintainer will either file a bug report or make a patch, or neither. Source: I maintain distro packages.
- bombolo 4y ago
  But something building doesn't mean that it will work. There can be changes that are different than function signature changes. Where dependency pinning is the norm, there is a culture of breaking API compatibility. And you might not have a compiler error to inform you that the API has changed. Sometimes all you have is a commit message.

The popular Rust tool "ripgrep" uses a lock file for development (you can see it in the GitHub repo), and yet is in the official repositories for homebrew, various Windows package managers, Arch, Gentoo, Fedora, some versions of openSUSE, Guix, recent versions of Debian (and therefore Ubuntu), FreeBSD, OpenBSD, NetBSD, and Haiku. With all due respect, I don't think you're correct.

bombolo 4y ago
And how much rust software is packaged in distributions? Almost none. They haven't figured out the procedures, because distributions really really don't want pinned stuff around. Homebrew, windows, arch all have very very relaxed processes to enter. There is no QA, you can just do whatever you want. I mean more like Fedora and Debian.
- dontlaugh 4y ago
  The distros will eventually stop this dangerous practice of mixing and matching versions for all dependencies. It can only work for a small set of system components, which is what every other OS does.
  - bombolo 4y ago
    It's more dangerous to let people pin dependencies and have vulnerable libraries in use forever.
    - burntsushi 4y ago
      Who says the distros are using the lock file? AFAIK, Debian doesn't use ripgrep's lock file, for example. They don't have to, because of semver.
      - LtWorf 4y ago
        What's the point of the lockfile then?
        burntsushi 4y ago
        For people that want to build with the exact set of dependency versions tested by upstream. Just because some distros don't use them doesn't mean there isn't any point.
- burntsushi 4y ago
  Bottom line is that the lock file in ripgrep's repo hasn't prevented it from being packaged. And I haven't heard of any distro maintainer complain about any lock file in any Rust program ever. So you're just plain empirically wrong about lock files preventing Rust programs from being packaged. You've now moved on to talking about something else, which is "how much Rust software is packaged." Well, apparently enough that Debian has Rust packaging policy[1]. I'll give you one guess at what isn't mentioned in that policy. Give up? Lock files! [1]: https://wiki.debian.org/Teams/RustPackaging/Policy https://wiki.debian.org/Teams/RustPackaging/Policy
  - bombolo 4y ago
    > So you're just plain empirically wrong about lock files preventing Rust programs from being packaged. My mistake, seems rust packagers gave up on decent packaging. It isn't so for the python policy, I can assure you :)
    - burntsushi 4y ago
      I haven't heard anyone complain about how Rust programs are packaged. Take your passive aggressive bullshit somewhere else.
      - sseagull 4y ago
        How Linux package managers handle these newer languages with their own package managers (including rust) is an ongoing pain point. Here’s an article from 2017 about it, and I don’t know if things have improved: https://lwn.net/Articles/712318/ https://lwn.net/Articles/712318/
        burntsushi 4y ago
        I didn't say it wasn't a pain point or that there weren't challenges. I said I don't hear about people complain about how Rust programs are packaged. Not that the packaging of Rust programs (among others) itself doesn't present interesting challenges depending on the policies of a particular distro. Archlinux, for example, has far fewer problems than Debian because of differences in policy. The poster I was responding to was literally posting false information. I'm correcting it. This doesn't need to turn into a huge long sprawling discussion about packaging Rust programs. The main point that I was making is that lock files do not prevent Rust programs from being packaged. bombolo then went off on their own little tangents spouting nonsense without bothering to acknowledge their mistake.

throwawaaarrgh 4y ago

Distros can keep their own lock file that is based on their own release branch's versions. If it doesn't build, the pkg maintainer will either file a bug report or make a patch, or neither. Source: I maintain distro packages.

bombolo 4y ago
But something building doesn't mean that it will work. There can be changes that are different than function signature changes. Where dependency pinning is the norm, there is a culture of breaking API compatibility. And you might not have a compiler error to inform you that the API has changed. Sometimes all you have is a commit message.