Joachim Breitner

How forky may one maintain a Debian package?

Published 2010-07-17 in sections English, Debian.

I maintain most of my Debian packages because I use them myself. Sometimes, I have some needs that go slightly beyond what is currently offered by the software. This is not a problem: Debian ships Free Software and I can program, therefore I can patch the software to also do what I want it to do. Trying to be a good member of the Free Software community, I then submit the patch to the upstream author. If he accepts the patch (which is usually the case), everything is fine. But what if he does not reply to the report or rejects it because he does not want this feature (although the patch is technically fine)? I see two options:

  1. I could continue to use a privately patched and built version of the package, while separately building packages for Debian. This way, Debian ships the software as intended by the upstream maintainer while I can use the features I need. On the other hand, I would not be using the version that I upload to Debian, which is not good, and it causes double work when a a new version is released.
  2. I could upload a package to Debian that contains my patch. The technical infrastructure to add patch in Debian packages has always been there... I would actually use the package as it is in Debian and only manage one line of versions. But would I be abusing my powers as a Debian maintainer? If I were not the maintainer, I could not make this decision by myself (this happend with my patch to nagstamon). Plus it could have a negative effect on the Debian-upstream relationship.

How do other Debian Developers handle such issues? The actual case I’m considering is a feature enhancement for link-monitor-applet (but I only just wrote the patch, so it does not yet fall in the category “upstream does not reply”).

Comments

Do what's best for your users. That's my advice. If the changes you want to make enhance the package in a way that everyone would appreciate it, then put it into the Debian package. If not, then don't.



As an example of a downstream-only patch, Debian is the home of the GNU/kFreeBSD port of Mono - it's only a small patch, but it's something upstream really didn't care about - but we did.
#1 Jo Shields (Homepage) am 2010-07-17
Don't use a Debian package as a means to fork while keeping the same name. I would suggest maintaining a fork independent from Debian, following whatever procedures you would if you did so, and then packaging that fork.
#2 Anonymous am 2010-07-17
I’m not really considering full forks – just small patches that enhance the program in minor, non-critical ways. Usually by adding an option that is off by default – would that be different?
#3 Joachim Breitner (Homepage) am 2010-07-17
Not in my view. I don't believe that feature-adding patches belong in a package that isn't marked as being explicitly divergent from upstream (eg. mutt-patched).
#4 Anonymous am 2010-07-18
If the patch is useful to you, chances are it will be useful to others as well, so please apply your patches.
#5 Marco am 2010-07-18
My take: get upstream’s opinion (but do not feel obligated to follow it if it is wrong). If there is risk of breakage, patch experimental first.
#6 Jonathan Nieder am 2010-07-19
Am not a DD, but I'd go for including that patch, with a README.Debian (noting the rationale for the patch, and maybe a link to why upstream refused it). If someone wants pure upstream, they can open a bugreport explaining why upstream's version rocks and/or just use pure upstream. A good idea is to discuss it on debian-devel-list first before doing any of these.
#7 Tshepang Lekhonkhobe (Homepage) am 2010-07-18
I maintain a fair amount of packages myself too (see Homepage link), and there are also some with unresponsive upstreams. When it comes to applying patches, especially such that users would like to have added, I see it as my job of package maintainer to decide wether it makes sense to keep it in Debian when Upstream doesn't respond or like it.



Actually, I have a pretty nice story about that. The beep package's Upstream author was unresponsive for me for a pretty long period of time. The package got up to Debian revision 24 over the last years (8 or such?) and piled up a fair amount of patches. Just recently I tried to contact him again - and finally got a response, including that he picked up all of my patches and did an instant new release with them.



Long story cut short: You'll never know wether non-responsive upstreams might come back at some point and be thankful for your job. It might even happen that you start to become the upstream author for such packages. Having the package in a strict maintenance stage with a dead upstream often enough isn't helpful.
#8 Gerfried Fuchs (Homepage) am 2010-07-19
Well… look at the CVS package. It even

breaks checkouts’ hashes because the

date format inserted into $Id$ and si-

milar tags was broken (converted from

YYYY/MM/DD to ISO YYYY-MM-DD).



If they can do THAT, you can surely put

your own fixes/improvements into your

package – maybe upstream will pick them

up that way. Maybe other OS packagers

will pick them up from you (BTST).



So, by all means, go on, but please try

not to break too much (unlike cvs) ☺
#9 mirabilos (Homepage) am 2010-07-19
I'm not a DD, but I've been a user for a long time.



I would say as package maintainer you have the responsibility to release the "best" package you can for the user.



You could ask yourself how would you respond to this if it was a wishlist bug report that included the patch?



As maintainer your opinion of what is "best" should probably be pretty heavily weighted. The fact that as a user you feel the need to have the patch applied is a pretty good indicator what you believe is best. The two packages doesn't really pass the "eat your own dog food" test. If it is a configurable feature or just sits there idly in a menu, I'd rather have the choice for more features.



Posting to debian-devel is a good way to get opinions, if you feel the change requires more thought, but in the end you still have to make the decision. This can be a political mess though, and from what I've seen is a great way to avoid making a decision.



As far as relationship to upstream. I would not interpret no response as a rejection. I'd interpret it as don't care, you can't have a negative effect on a relationship that isn't there. It's a two way street, you're not dirt. You are their connection to one of the largest package archives and user bases. If they actually do reject your patch, find out why. They should be the technical experts and probably have a good reason. Maybe they are planning on adding the feature in a different way in the near future. Maybe they would prefer it coded slightly differently.

Remember ideas are children of the mind. Developers can get unusual attachments to their code. Maybe they want you too sign over rights to the patch, or join their development circle. Maybe they are just jerks who think that only they can write code for their baby. Maybe they don't see the obviously existing use case, and just need it explained to them. Maybe they know there is a better way to accomplish the same thing.
#10 Ted Kotz (Homepage) am 2010-07-19
I'm not a DD.



In my view the risk of adding features in the debian version of the package probably outweighs the feature. If it weren't a niche feature then upstream would have accepted it. Or maybe it just goes against upstream's vision for the software.



My advice is to take on the responsibility of upstream by becoming upstream. Upstream developers almost always run the latest and greatest version of the software, instead of the debian packaged version.



So collect your patches, improve the software, and distribute the fork when you think you have something sufficiently different. If you develop a vision for the software, you might even find yourself rejecting patches that other people send you.
#11 Ben Asselstine am 2010-07-20

Have something to say? You can post a comment by sending an e-Mail to me at <mail@joachim-breitner.de>, and I will include it here.