4 ms·

Actually, it's still a pain for package maintainers. Take a look at mod_wsgi for apache as an example, it's maintained as a completely separate package (the rpm

by snuxoll 11y ago

Actually, it's still a pain for package maintainers. Take a look at mod_wsgi for apache as an example, it's maintained as a completely separate package (the rpmspec and dist-git trees are totally independent from apache) - when the httpd package gets upgraded mod_wsgi doesn't have to be rebuilt at all. This is important, in fact, because rebuilding a package means updating the spec file, bumping the release, and submitting a new build to koji - not something you want to do for loadable modules every time httpd is updated. This is going to create headaches for anyone wanting to package nginx, either they will have to compile all the modules when building nginx (creating many sub-packages) or there will have to be coordination between package maintainers to do a mass rebuild of all loadable modules every time the nginx package gets bumped. Neither situation is desirable, and I hope they release a stable ABI because until then nobody is going to waste time packaging loadable modules.

Florin_Andrei 11y ago
Wow. That basically means their current module scheme is useless for package maintainers.
- snuxoll 11y ago
  Pretty much. Like I said, technically you could just have the build for nginx also include all of the modules and just split them up into sub-packages, but that defeats the entire point of having loadable modules that can be compiled independently.
  - voltagex_ 11y ago
    This is off topic, but I think there should be more tutorials for developers along the lines of "how to make life easier for packagers". Sidenote: creating Debian packages is an intimidating task.
    - snuxoll 11y ago
      1. Don't use a million dependencies that aren't already included in the majority of distributions. As a packager, I have no desire to maintain 20 complicated libraries you decided to depend on just to include your application in the package collection. A couple is fine, and the flatter your dependency tree is the less painful it is for a package maintainer to deal with. If you must include a dependency then please keep the transitive ones under control! 2. Use a standard build/packaging system. autotools, cmake, scons, setuptools/distutils, maven, gem (read: not bundler), cpan, etc. Whatever is considered a "standard" way of building and releasing software in the language you are writing it in is acceptable, using hacked together Makefiles and build scripts is generally a quick way to make packagers hate you and not want to waste time getting your software built. 3. Don't vendor dependencies - if you do then support the use of system-installed libraries in their place. I won't package software that insists on vending dependencies, I'm happy to package an extra library or two but I don't have that option if you don't support it. 4. Please support a standard installation mechanism if at all possible. I can relocate your build artifacts to the buildroot if necessary, but then I have to maintain it as the upstream changes - and distributions may be inconsistent with each other. If you are using a standard build system this should come for practically free unless you've done some nasty hacks, in which case please reconsider the modifications you have made. Debian packaging is pretty simple but I find the decision to use Makefile's for debian/rules to be a little annoying. rpmspec's are a lot clearer and rpm macro's are a lot easier to intuit since you can easily use rpmspec -e to see what they expand to, versus the blackbox that is the debhelper scripts sometimes. If you are new to packaging seriously take a look at making RPM's your first stop, rpmdev-newspec has a lot of templates for spec files that make getting started with any project that uses a standard build system super-easy (automake, cmake, python, ruby, perl, etc).
      - jrc7 11y ago
        1. As a developer, I couldn't care less about making your life easier at the expense of making mine more difficult. 3. I couldn't care less what you won't package. Especially so if it's due to prioritizing your own needs over everyone else's. Take it or leave it. 4. Distributions are already woefully inconsistent anyway. If you're going to package something, the entire burden is on you. Distributions have had too much influence over upstream projects for way too long. Thank god people are finally starting to reject their diva-like, our-way-or-the-highway attitudes. I have been a package maintainer for both Fedora and Debian, and frankly, for things outside of the core OS/libs/compilers/tools, using deb/rpm packaging is very, very overrated. Likewise for dynamic linking.

by snuxoll 11y ago

Florin_Andrei 11y ago

Wow. That basically means their current module scheme is useless for package maintainers.

snuxoll 11y ago
Pretty much. Like I said, technically you could just have the build for nginx also include all of the modules and just split them up into sub-packages, but that defeats the entire point of having loadable modules that can be compiled independently.
- voltagex_ 11y ago
  This is off topic, but I think there should be more tutorials for developers along the lines of "how to make life easier for packagers". Sidenote: creating Debian packages is an intimidating task.
  - snuxoll 11y ago
    1. Don't use a million dependencies that aren't already included in the majority of distributions. As a packager, I have no desire to maintain 20 complicated libraries you decided to depend on just to include your application in the package collection. A couple is fine, and the flatter your dependency tree is the less painful it is for a package maintainer to deal with. If you must include a dependency then please keep the transitive ones under control! 2. Use a standard build/packaging system. autotools, cmake, scons, setuptools/distutils, maven, gem (read: not bundler), cpan, etc. Whatever is considered a "standard" way of building and releasing software in the language you are writing it in is acceptable, using hacked together Makefiles and build scripts is generally a quick way to make packagers hate you and not want to waste time getting your software built. 3. Don't vendor dependencies - if you do then support the use of system-installed libraries in their place. I won't package software that insists on vending dependencies, I'm happy to package an extra library or two but I don't have that option if you don't support it. 4. Please support a standard installation mechanism if at all possible. I can relocate your build artifacts to the buildroot if necessary, but then I have to maintain it as the upstream changes - and distributions may be inconsistent with each other. If you are using a standard build system this should come for practically free unless you've done some nasty hacks, in which case please reconsider the modifications you have made. Debian packaging is pretty simple but I find the decision to use Makefile's for debian/rules to be a little annoying. rpmspec's are a lot clearer and rpm macro's are a lot easier to intuit since you can easily use rpmspec -e to see what they expand to, versus the blackbox that is the debhelper scripts sometimes. If you are new to packaging seriously take a look at making RPM's your first stop, rpmdev-newspec has a lot of templates for spec files that make getting started with any project that uses a standard build system super-easy (automake, cmake, python, ruby, perl, etc).
    - jrc7 11y ago
      1. As a developer, I couldn't care less about making your life easier at the expense of making mine more difficult. 3. I couldn't care less what you won't package. Especially so if it's due to prioritizing your own needs over everyone else's. Take it or leave it. 4. Distributions are already woefully inconsistent anyway. If you're going to package something, the entire burden is on you. Distributions have had too much influence over upstream projects for way too long. Thank god people are finally starting to reject their diva-like, our-way-or-the-highway attitudes. I have been a package maintainer for both Fedora and Debian, and frankly, for things outside of the core OS/libs/compilers/tools, using deb/rpm packaging is very, very overrated. Likewise for dynamic linking.