Thus spoke Sam Hartman <hartmans@mekinok.com> on 2001-10-12 13:43:47: > >>>>> "Gergely" == Gergely Nagy <algernon@debian.org> writes: > Gergely> tend to fall deeper into that pit. As an example, when > Gergely> there's no install target in the original Makefile, they > Gergely> patch it. Even if it would be an `install -m 0755 foo > Gergely> debian/foo/usr/bin/bar' line in debian/rules' install > Gergely> target. No, they go and patch the Makefile instead, > Gergely> introducing a great deal of junk into the diff. > > > Which is arguably correct, especially if they plan on sending the > change upstream. Disk is cheap and on the scales we are talking about > here, bandwith is not horribly expensive. If I think the bug is in > the upstream code, and I'm going to fix it in a clean manner, then > I'll fix it in the upstream code. This is especially true if I plan > to send the change back, but is often true even if I don't. I try to > make it be the case that I'd rather build a package on a non-Debian > system with the Debian diff applied (not using the debian rules file > of course) than without. > True enough. I tend to solve this by patching the Makefile, and sending it upstream, but using the debian/rules trick in the Debian package. > I think that by enforcing these types of constraints we are going > beyond our charter. Our job is to make sure that people have the > necessary skills to be Debian developers, not to enforce a particular > packaging style that we can't even agree is a good idea. Agreed. My mail wasn't about enforcing my style, I tried to point out things I dislike. What I'd like to enforce, is that people know what they are doing. Of course, I'll try to influence my applicants with my style, but if we disagree on some minor points, I won't complain much. However, if they do such things as leaving the dh_make configure target there, empty, not doing anything, I get angry. > P.S. I think I disagree about removing the commented out debhelper > commands. I believe thbelieve the space they take up is justified by > the convenience of enabling the feature/remembering the existence of > the feature when it is useful. I recognize this is more a statement > on how much I value saving space than anything else. If there's a chance that they'll be used (like dh_installmenu), then sure, they can stay. But for a game, there's probably not much point keeping dh_installinit around. I may have been unclear: I meant that commands that will not be used in the near or foreseeable future, should be removed. Those which will be, can stay (however, I prefer removing those too, but that's just me).
Attachment:
pgpD4Ht2pPKKN.pgp
Description: PGP signature