Russ Allbery wrote: > Some of that divergence is, realistically, bugs that won't be fixed. For > example, I patch the Shibboleth SP Makefile because I remove one XML > schema which is under a non-free license (no modification allowed). > Realistically, that upstream difference isn't ever going to go away, Yeah, I can come up with my own examples of that too, of course. The benefits then just come down to clearly publishing the changes, and maybe allowing other distros to use them, etc. As far as just publishing unmergable patches like this goes, there's not a lot of difference between using the BTS, and using a patches.d.o. > Some of the divergence, and here I'm particularly thinking of FHS tweaks, > needs a fair bit of work to integrate upstream. I'm honestly of two minds > whether it's better to carry a simple patch in Debian to put things in the > right location or spend the effort to develop complex Autoconf plus build > system fixes to add an --enable-fhs option or the like to upstream while > maintaining backward compatibility with their traditional installation > locations, and I've run into that problem on several occasions. But I > think there too it's still reasonable to consider it a bug, just one of > those bugs that's likely to sit in the BTS for quite a long time. Or you can just let upstream know that hey, here's these changes that we make, they're obviously debian specficic, but perhaps they can see an easy way to generalise them, or perhaps it's worth their time to generalise them for other reasons. > The one that I'm the most worried about is keeping the patch in the bug up > to date when things change in the Debian package. Putting it there in the > first place is already something requiring manual action, but as it gets > merged with newer versions of upstream, I'm usually not thinking about > that particular bug and having to manually update the BTS with the results > of those merges would be quite annoying. I was assuming that, if a VCS could automatically manage the merge, then the patch in the BTS would not be too out of date for upstream to be able to use it. Now, if you have to manually fix the merge, I agree that remembering which bugs to go update could become annoying. > I'd also really like it if whatever system we use could figure out on its > own when a patch was merged upstream and went away (as you address later). > It's a bit different than the usual bug closing case, which is handled > manually, in that I as a Debian maintainer generally haven't taken any > explicit action in that case; I just packaged a new upstream version and > as a side effect a bunch of my branches now no longer have differences > from upstream. But there again I can imagine tools that would make it > automatic enough for me, and none of them seem conceptually hard. Hmm, another thought is, I sometimes have a changelog like this: * New upstream release. - Including my fix for foo. - And a better approach than my old hack to fix bar. It would be nice to be able to add bug numbers to close the divergences when I'm writing that. (And then an automatic system closing any I forget to mention would be nice.) -- see shy jo
Attachment:
signature.asc
Description: Digital signature