8 ms·

I think the gripe is that it's never been as easy as it could be to say "OK, I'm going to make a change in this here source file, then run the result on my mach

I think the gripe is that it's never been as easy as it could be to say "OK, I'm going to make a change in this here source file, then run the result on my machine while keeping everything else the same". For example if I'm reporting a bug and I have a proposed patch, it would be nice to be able to say "I've been running with this patch for the last month and it's been fine". Ideally there'd be a coherent way to download the source for a particular package, rebuild it, and have the system use the rebuilt result. Bonus marks if it did something useful when a newer version of the package came along. I think https://packages.debian.org/sid/dgit https://packages.debian.org/sid/dgit is an attempt to make the download-and-rebuild part look more uniform, but I think there's still work to be done to make it easy to substitute the result for the distro package.

michaelmrose 8y ago
This is trivial on funtoo/gentoo you just make a private tree of ebuild files containing only the packages that you care about modifying with the patches located in the same directory tree and applied by adding the patch to the ebuild. You can also host this somewhere so others can run/test your modified version easily. No real special infrastructure required they can sync this directory via git. There are of course downsides. The annoyance of building updates and discovering bugs not discovered by others by some unique set of patches / build time options.
blihp 8y ago
That's a valid complaint (I too wish it were simpler) but am not sure how feasible that is given the myriad of ways upstream packages are managed and the varying degrees to which they do or don't support distros in general, let alone a specific one like Debian. I think that's part of the reason Debian has become such a popular upstream distro: it converts an incoming Tower of Babel collection of source repos into a reasonably coherent and standardized set of packages.
viraptor 8y ago
What's missing from: "apt-get source the-package", add patches, "pbuilder build the-package.dsc" ? (I'm assuming that pbuilder was already configured to work)
- EE84M3i 8y ago
  FWIW As someone that touches debian package building once in a blue moon, it seems like there's wide variability into which is the "right way" to do the actual build step and that everyone has their own artisanal preference. pbuilder, debuild, debootstrap, dpkg-buildpackage, sbuild, fakeroot all leave me scratching my head.
  - viraptor 8y ago
    If we're taking about the reproducible packages, then I believe only pbuilder is a valid answer here. (maybe sbuild, I haven't used that one) debootstrap / fakeroot / dpkg are part of the pbuilder system, not full solutions. But yeah, I noticed that Debian is not going out of its way to advertise one blessed solution.
- mjw1007 8y ago
  Two main things, I think: - coping with the variety of different patch systems used in Debian packages - an integrated way of keeping track of which locally-built packages have been installed Also of course getting pbuilder set up, and knowing that it's an option in the first place. In an ideal world I'd like to be able to say that the only knowledge you need to modify one of the programs on your system is the language that the program is written in, rather than having to also fill your head with bits of distro-specific arcana. I do think that things are better than they were even a few years ago (in particular, the variety-of-different-patch-systems situation is getting noticeably better).
  - andrewshadura 8y ago
    1) These days, there's only quilt. 2) There isn't really difference between locally built packages and ones from the distro, but one way to distinguish yours is to append a suffix to your versions, e.g. andrewshX in my case, where X is an incrementing number.

michaelmrose 8y ago

This is trivial on funtoo/gentoo you just make a private tree of ebuild files containing only the packages that you care about modifying with the patches located in the same directory tree and applied by adding the patch to the ebuild. You can also host this somewhere so others can run/test your modified version easily. No real special infrastructure required they can sync this directory via git. There are of course downsides. The annoyance of building updates and discovering bugs not discovered by others by some unique set of patches / build time options.

blihp 8y ago

That's a valid complaint (I too wish it were simpler) but am not sure how feasible that is given the myriad of ways upstream packages are managed and the varying degrees to which they do or don't support distros in general, let alone a specific one like Debian. I think that's part of the reason Debian has become such a popular upstream distro: it converts an incoming Tower of Babel collection of source repos into a reasonably coherent and standardized set of packages.

viraptor 8y ago

What's missing from: "apt-get source the-package", add patches, "pbuilder build the-package.dsc" ? (I'm assuming that pbuilder was already configured to work)

EE84M3i 8y ago
FWIW As someone that touches debian package building once in a blue moon, it seems like there's wide variability into which is the "right way" to do the actual build step and that everyone has their own artisanal preference. pbuilder, debuild, debootstrap, dpkg-buildpackage, sbuild, fakeroot all leave me scratching my head.
- viraptor 8y ago
  If we're taking about the reproducible packages, then I believe only pbuilder is a valid answer here. (maybe sbuild, I haven't used that one) debootstrap / fakeroot / dpkg are part of the pbuilder system, not full solutions. But yeah, I noticed that Debian is not going out of its way to advertise one blessed solution.
mjw1007 8y ago
Two main things, I think: - coping with the variety of different patch systems used in Debian packages - an integrated way of keeping track of which locally-built packages have been installed Also of course getting pbuilder set up, and knowing that it's an option in the first place. In an ideal world I'd like to be able to say that the only knowledge you need to modify one of the programs on your system is the language that the program is written in, rather than having to also fill your head with bits of distro-specific arcana. I do think that things are better than they were even a few years ago (in particular, the variety-of-different-patch-systems situation is getting noticeably better).
- andrewshadura 8y ago
  1) These days, there's only quilt. 2) There isn't really difference between locally built packages and ones from the distro, but one way to distinguish yours is to append a suffix to your versions, e.g. andrewshX in my case, where X is an incrementing number.