Comments on Christian thoughts in a tech world: Minimal dependencies and backports

@perigrin: with CPAN modules it is easy to test mo...

2009-05-06T10:31:08.909-07:00

@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?

«Honestly, I also don't really understand why lint...

2009-04-28T11:18:00.066-07:00

«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).

Thank you all for the comments. @Kai & perigrin: ...

2009-04-28T10:51:39.303-07:00

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 ?

Finally I've got something to link to when I ask p...

2009-04-28T10:37:09.312-07:00

Finally I've got something to link to when I ask people not to use high debhelper versions for the sake of doing so ;).

I started a comment, but it got way too long. My ...

2009-04-28T09:49:20.798-07:00

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.

Sometimes a dependency isn't stipulating what a mo...

2009-04-28T08:35:54.978-07:00

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 think the issue is that the packager does not kn...

2009-04-28T03:32:50.163-07:00

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?