4 ms·

There's a big gap between making a working .deb file and getting something to pass QA to get into the archive. It's been quite a while since I looked at it, bu

There's a big gap between making a working .deb file and getting something to pass QA to get into the archive. It's been quite a while since I looked at it, but the documentation was fragmented and not up to date. Things have gotten better now you can use git-buildpackage [0], but it still feels arcane. Challenge - take a package like wget and try to update it to the latest version from upstream Git (or whatever). It should be one or two commands but I've never been able to make it work easily. It's even harder if you're trying to port something across from Ubuntu or to use a fork like wget-lua [1] 0: http://honk.sigxcpu.org/projects/git-buildpackage/manual-html/ http://honk.sigxcpu.org/projects/git-buildpackage/manual-htm... 1: https://github.com/alard/wget-lua https://github.com/alard/wget-lua

mmt 8y ago
> There's a big gap between making a working .deb file and I assume none of us is even talking about this case. That is, a trivially working .deb could provide little more functionality than a tarball, so that's hardly interesting. > getting something to pass QA to get into the archive. The last part I have no knowledge of, since I only ever put my packages into internal archives. Were there political aspects, or only technical? For the technical, I'm still looking for (ideally from the GP, but from anyone who shares the opinion), specifics. > the documentation was fragmented and not up to date. This is a common complaint I hear/read, and I recall it was part of my initial learning investment, figuring out where to go for what information. Now it's mostly bookmarked, and changes tend not to be drastic. > Things have gotten better now you can use git-buildpackage One thing I found, repeatedly and consistently, was that every single external (i.e. not from Debian) utility that tried to make the process "better" or "easier" ultimately did the opposite, since it would hide or abstract away an important aspect of the packaging process. > Challenge - take a package like wget and try to update it to the latest version from upstream Git (or whatever). It should be one or two commands but I've never been able to make it work easily. I can't recall if I've done wget specifically, but I've done this kind of thing before without much issue, assuming that latest version actually builds and runs on that platform without porting work and without needing a ton of new dependencies (or new versions of existing ones). I tended to find most of my time was spent in chasing down and re-packaging various libraries whose older versions were no longer good enough. > It's even harder if you're trying to port something across from Ubuntu I'm not sure what you mean, since Ubuntu is already using Debian packaging. > or to use a fork like wget-lua Certainly forks are going to be more effort, but my experience is that this is true even in their unpackaged state, if they require more exotic (or specific) dependencies be pre-installed, a custom build process, or any porting work. If someone had already done all that work, comprehensively documented it, but merely not translated it into debianization, it would save me a ton of time in creating a custom package.
- voltagex_ 8y ago
  Would you be willing to share your bookmarks?
  - mmt 8y ago
    Sure. These were approximately chronological order (though Firefox's Sync has occasionally swapped a couple). They're also at least a couple years old, so some may be much older than that and are now dead links without the use of archive.org. You can somewhat see the evolution of the python package debianization ("python policy"). http://www.debian.org/doc/maint-guide/ch-update.en.html http://www.debian.org/doc/maint-guide/ch-update.en.html http://www.gnu.org/software/make/manual/make.html#Automatic-Variables http://www.gnu.org/software/make/manual/make.html#Automatic-... http://www.debian.org/doc/debian-policy/ http://www.debian.org/doc/debian-policy/ http://www.debian.org/doc/packaging-manuals/python-policy/ap-packaging_tools.html#s-pysupport http://www.debian.org/doc/packaging-manuals/python-policy/ap... http://www.gnu.org/software/make/manual/make.html#Functions http://www.gnu.org/software/make/manual/make.html#Functions http://www.debian.org/doc/debian-policy/ch-relationships.html http://www.debian.org/doc/debian-policy/ch-relationships.htm... http://www.debian.org/doc/debian-policy/ch-maintainerscripts.html http://www.debian.org/doc/debian-policy/ch-maintainerscripts... http://wings.buffalo.edu/computing/ublinux/Ubuntu.php http://wings.buffalo.edu/computing/ublinux/Ubuntu.php http://www.debian.org/doc/developers-reference/ http://www.debian.org/doc/developers-reference/ http://webapps-common.alioth.debian.org/draft-wac/html/ http://webapps-common.alioth.debian.org/draft-wac/html/ http://www.gnu.org/software/make/manual/make.html#Text-Functions http://www.gnu.org/software/make/manual/make.html#Text-Funct... http://www.debian.org/doc/packaging-manuals/python-policy/ch-python.html http://www.debian.org/doc/packaging-manuals/python-policy/ch... http://webapps-common.alioth.debian.org/draft/html/ http://webapps-common.alioth.debian.org/draft/html/ http://www.debian.org/doc/debian-policy/ch-files.html http://www.debian.org/doc/debian-policy/ch-files.html http://wiki.debian.org/DebianPython/NewPolicy http://wiki.debian.org/DebianPython/NewPolicy

mmt 8y ago

> There's a big gap between making a working .deb file and I assume none of us is even talking about this case. That is, a trivially working .deb could provide little more functionality than a tarball, so that's hardly interesting. > getting something to pass QA to get into the archive. The last part I have no knowledge of, since I only ever put my packages into internal archives. Were there political aspects, or only technical? For the technical, I'm still looking for (ideally from the GP, but from anyone who shares the opinion), specifics. > the documentation was fragmented and not up to date. This is a common complaint I hear/read, and I recall it was part of my initial learning investment, figuring out where to go for what information. Now it's mostly bookmarked, and changes tend not to be drastic. > Things have gotten better now you can use git-buildpackage One thing I found, repeatedly and consistently, was that every single external (i.e. not from Debian) utility that tried to make the process "better" or "easier" ultimately did the opposite, since it would hide or abstract away an important aspect of the packaging process. > Challenge - take a package like wget and try to update it to the latest version from upstream Git (or whatever). It should be one or two commands but I've never been able to make it work easily. I can't recall if I've done wget specifically, but I've done this kind of thing before without much issue, assuming that latest version actually builds and runs on that platform without porting work and without needing a ton of new dependencies (or new versions of existing ones). I tended to find most of my time was spent in chasing down and re-packaging various libraries whose older versions were no longer good enough. > It's even harder if you're trying to port something across from Ubuntu I'm not sure what you mean, since Ubuntu is already using Debian packaging. > or to use a fork like wget-lua Certainly forks are going to be more effort, but my experience is that this is true even in their unpackaged state, if they require more exotic (or specific) dependencies be pre-installed, a custom build process, or any porting work. If someone had already done all that work, comprehensively documented it, but merely not translated it into debianization, it would save me a ton of time in creating a custom package.

voltagex_ 8y ago
Would you be willing to share your bookmarks?
- mmt 8y ago
  Sure. These were approximately chronological order (though Firefox's Sync has occasionally swapped a couple). They're also at least a couple years old, so some may be much older than that and are now dead links without the use of archive.org. You can somewhat see the evolution of the python package debianization ("python policy"). http://www.debian.org/doc/maint-guide/ch-update.en.html http://www.debian.org/doc/maint-guide/ch-update.en.html http://www.gnu.org/software/make/manual/make.html#Automatic-Variables http://www.gnu.org/software/make/manual/make.html#Automatic-... http://www.debian.org/doc/debian-policy/ http://www.debian.org/doc/debian-policy/ http://www.debian.org/doc/packaging-manuals/python-policy/ap-packaging_tools.html#s-pysupport http://www.debian.org/doc/packaging-manuals/python-policy/ap... http://www.gnu.org/software/make/manual/make.html#Functions http://www.gnu.org/software/make/manual/make.html#Functions http://www.debian.org/doc/debian-policy/ch-relationships.html http://www.debian.org/doc/debian-policy/ch-relationships.htm... http://www.debian.org/doc/debian-policy/ch-maintainerscripts.html http://www.debian.org/doc/debian-policy/ch-maintainerscripts... http://wings.buffalo.edu/computing/ublinux/Ubuntu.php http://wings.buffalo.edu/computing/ublinux/Ubuntu.php http://www.debian.org/doc/developers-reference/ http://www.debian.org/doc/developers-reference/ http://webapps-common.alioth.debian.org/draft-wac/html/ http://webapps-common.alioth.debian.org/draft-wac/html/ http://www.gnu.org/software/make/manual/make.html#Text-Functions http://www.gnu.org/software/make/manual/make.html#Text-Funct... http://www.debian.org/doc/packaging-manuals/python-policy/ch-python.html http://www.debian.org/doc/packaging-manuals/python-policy/ch... http://webapps-common.alioth.debian.org/draft/html/ http://webapps-common.alioth.debian.org/draft/html/ http://www.debian.org/doc/debian-policy/ch-files.html http://www.debian.org/doc/debian-policy/ch-files.html http://wiki.debian.org/DebianPython/NewPolicy http://wiki.debian.org/DebianPython/NewPolicy