[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: The Helper Rant

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

> 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

Attachment: pgpD4Ht2pPKKN.pgp
Description: PGP signature

Reply to: