4 ms·

Does this make the downstream packagers’ jobs harder — they must now presumably have Perl, Bison, Flex and DocBook installed on the packaging machines?

b112 2y ago
Everything but docbook seems pretty standard.
mhio 2y ago
Debian already had them https://salsa.debian.org/postgresql/postgresql/-/blob/16/debian/control#L13-20 https://salsa.debian.org/postgresql/postgresql/-/blob/16/deb... https://salsa.debian.org/postgresql/postgresql/-/compare/16...17#58ef006ab62b83b4bec5d81fe5b32c3b4c2d1cc2 https://salsa.debian.org/postgresql/postgresql/-/compare/16....
kpcyrd 2y ago
The build server now needs the actual build dependencies instead of relying on pre-built intermediate build artifacts. This is a good thing, and should be expected from anything that claims to "build from source".
- carderne 2y ago
  I know it’s a good thing. I’m just curious to what degree packagers see this as extra work. Seems like probably not.
  - vsl 2y ago
    It's going to be a trivial amount of extra work. Packaging build systems (well, the mainstream ones: Debian, RPMs, ebuilds etc.) have the concept of runtime and build-time dependencies, so the maintainers will just need to add a few more packages to the build deps list.
  - EuAndreh 2y ago
    IIRC Debian has a policy on preferring to generated files themselves. I couldn't find the link to it right now, though.
    - EuAndreh 2y ago
      s/generated/generate/
    - pabs3 2y ago
      Some info on here: https://wiki.debian.org/AutoGeneratedFiles https://wiki.debian.org/AutoGeneratedFiles
      - EuAndreh 2y ago
        Yep, that says not to include generated files in VCS. I've also seen the bison and flex output included in VCS, and the same guidelines apply.
  - bluGill 2y ago
    Many distributions have a policy of not using generated files, and more are implementing it after the xz hack. Most package systems have (not just Debian) have the concept of build and deploy dependencies. It is of course more work, and package systems tend to not be well documented and so it is hard to figure out, but it is possible: if you ask the experts they will help
chubot 2y ago
Hm the article was pretty unclear to me, and I read several times 1) Do they commit the generated flex/bison to git now? So tarballs match git 2) Or do they now leave it up to the end user to generate flex/bison? And run their custom Perl scripts, etc.
- sjamaan 2y ago
  As I understood it, they used to generate the flex/bison stuff because they relied on very specific versions of those. But now those versions are commonly available, they rely on the user to generate these.
  - gpvos 2y ago
    I understood they just need to be recent enough.
- gpvos 2y ago
  2.
XorNot 2y ago
This doesn't seem like a problem though? As long as it's open source with packages available, that's just a CI process. At some point those machines are building those packages anyway, so the content is also already cached.

b112 2y ago

Everything but docbook seems pretty standard.

mhio 2y ago

Debian already had them https://salsa.debian.org/postgresql/postgresql/-/blob/16/debian/control#L13-20 https://salsa.debian.org/postgresql/postgresql/-/blob/16/deb... https://salsa.debian.org/postgresql/postgresql/-/compare/16...17#58ef006ab62b83b4bec5d81fe5b32c3b4c2d1cc2 https://salsa.debian.org/postgresql/postgresql/-/compare/16....

kpcyrd 2y ago

The build server now needs the actual build dependencies instead of relying on pre-built intermediate build artifacts. This is a good thing, and should be expected from anything that claims to "build from source".

carderne 2y ago
I know it’s a good thing. I’m just curious to what degree packagers see this as extra work. Seems like probably not.
- vsl 2y ago
  It's going to be a trivial amount of extra work. Packaging build systems (well, the mainstream ones: Debian, RPMs, ebuilds etc.) have the concept of runtime and build-time dependencies, so the maintainers will just need to add a few more packages to the build deps list.
- EuAndreh 2y ago
  IIRC Debian has a policy on preferring to generated files themselves. I couldn't find the link to it right now, though.
  - EuAndreh 2y ago
    s/generated/generate/
  - pabs3 2y ago
    Some info on here: https://wiki.debian.org/AutoGeneratedFiles https://wiki.debian.org/AutoGeneratedFiles
    - EuAndreh 2y ago
      Yep, that says not to include generated files in VCS. I've also seen the bison and flex output included in VCS, and the same guidelines apply.
- bluGill 2y ago
  Many distributions have a policy of not using generated files, and more are implementing it after the xz hack. Most package systems have (not just Debian) have the concept of build and deploy dependencies. It is of course more work, and package systems tend to not be well documented and so it is hard to figure out, but it is possible: if you ask the experts they will help

chubot 2y ago

Hm the article was pretty unclear to me, and I read several times 1) Do they commit the generated flex/bison to git now? So tarballs match git 2) Or do they now leave it up to the end user to generate flex/bison? And run their custom Perl scripts, etc.

sjamaan 2y ago
As I understood it, they used to generate the flex/bison stuff because they relied on very specific versions of those. But now those versions are commonly available, they rely on the user to generate these.
- gpvos 2y ago
  I understood they just need to be recent enough.
gpvos 2y ago
2.

XorNot 2y ago

This doesn't seem like a problem though? As long as it's open source with packages available, that's just a CI process. At some point those machines are building those packages anyway, so the content is also already cached.