I've been packaging for a production environment for nearly three years now. We have a lot of machines using old systems, such as sarge and etch, and my work is often to backport new software to these OSes. While the work is fun, I often find myself fighting with dependencies, and especially with debhelper build dependencies.
For example, I find more and more Perl packages in Debian that depend on debhelper 7. I tried to backport debhelper 7 for etch, but it pulled all sorts of things with it, all the way to dpkg-dev, which messed up the whole system, so I gave up. In this case, I have to end up upgrading debhelper 5 packages to newer upstream versions when I need, since using debhelper 7 is virtually impossible in sarge and etch.
In other cases, I find packages that build depend on debhelper 6 and have "6" in debian/compat. Changing the values to "5" doesn't prevent the build, so all that is to do is change the value back to "5".
Maybe it's me not understanding the concept of minimal dependency and compatibility, but I really don't get why it is a rule to keep bumping debhelper compability (and often, other libs too) when there is absolutely no need for it. If a program works with Perl 5.4, why make people believe it requires Perl 5.8 to run? There are still people running Perl 5.4 on old machines somewhere, who would be happy to not have to change the minimal dependencies to use a program that would run fine on their machines.
I understand very well that package development in the community is centered on new versions and that it's just easier to "force" people to upgrade their systems altogether (remember the "mysql-server" meta-packages magically upgrading from MySQL 4.1 to MySQL 5.0 in etch ?), but if Debian and Ubuntu want to be enterprise-class OSes, I think we ought to adapt better to the reality of production environments, and that includes making it easier for sysadmins to manage old systems without depending on new tools.
I'd be very happy to hear from the experience of other sysadmins in production environments regarding this issue.
April 28, 2009
Subscribe to:
Post Comments (Atom)
Posts
7 comments:
I think the issue is that the packager does not know whether it works with the old version. To find out, it needs to be tested, and who has an old system to test it on?
Sometimes a dependency isn't stipulating what a module *can* support, but what a module author *will* support.
I don't have the time or energy to make sure that code I write will run happily on perls older than 5.8.3. I honestly don't test things on Perl's older than 5.10.0 anymore but I don't (typically) use the 5.10.0 features so I feel safe in assuming that things will work on 5.8.3+. I set the earliest limits on my modules generally at 5.8.3 because that's the farthest back I feel I can safely guarantee my stuff should work on with the least amount of effort on my part.
As I get almost no compensation for what is effectively a hobby for me I optimize support for me not for you. The alternative is I stop contributing because I couldn't possibly satisfy every valid support request and still enjoy what I'm doing.
I started a comment, but it got way too long. My reply is here: http://joshuakugler.com/archives/15-Real-dependencies,-not-convenient-dependencies.html.
Finally I've got something to link to when I ask people not to use high debhelper versions for the sake of doing so ;).
Thank you all for the comments.
@Kai & perigrin: The fact that old libs cannot be tested is not a valid reason to bump to higher requirements imo. Let's say I have a package that build-depends on foo (>= 1.2.3). As I update this package, I find that my system now has foo=1.2.4. I am not able to test the compilation with foo 1.2.3, but it doesn't really matter imo, because I know that the autobuilders will use the most recent version of foo available for my system anyway. If ever the package doesn't build on foo < 1.2.4, I might get a bug report about that, and then I can update the dependencies accordingly, because I know it is necessary to do so.
In the case of debhelper/cdbs/dpatch/quilt/etc. dependencies, it is even trickier. Most packages marked as build-depending on debhelper >= 6 are actually packages that were made with debhelper 5 and no change has been made to the dh_* commands in debian/rules at all, so it is clear that the package would still build with debhelper 5. I believe it is fine to switch the package build-dependencies to debhelper >= 6 and compat 6 if the maintainer begins to use a feature that is debhelper 6 specific, which is quite rare.
Python packages using python-central are imo an example of justified build-dependencies, where it is obvious that using anything else will FTBFS, because the maintainer has made a choice of using python-central, which is good.
Honestly, I also don't really understand why lintian has to complain when debian/compat contains a value below 4. If a package could build on debhelper 3, is that bad?
@perigrin: I totally get your point of view on being a volunteer contributor. Most of the packages I get to backport are not from universe in Ubuntu. I mostly get to work on PHP, MySQL, Apache, etc. so these are packages maintained by Canonical to be certified for an enterprise-class OS, which I would love Ubuntu to be.
@RainCT: do you have other experience cases with this ?
«Honestly, I also don't really understand why lintian has to complain when debian/compat contains a value below 4. If a package could build on debhelper 3, is that bad?»
Debhelper levels 1, 2 and 3 have been deprecated, and debian/compat levels actually choose beetween different behaviours available for some of the tools (see «man debhelper»), so, the package will not benefit from some of the improvements in debhelper if it asks for an older version. But I guess you already know :).
«@RainCT: do you have other experience cases with this?»
As in your case, no. But I see lots of packages on REVU (and not only there) which use the latest debhelper version for no real reason. In those cases I usually ask the uploader to switch to a lower version or to explain why having the newest version is beneficial for his package (to put an example, he may really want to use a debian/clean file, for which compat level 7 is required).
@perigrin: with CPAN modules it is easy to test modules on older Perl version with help of cpantesters.
Raphaël: are these packages built automatically or updated manually?
Post a Comment