Gergely Nagy wrote:
> #! /usr/bin/env /usr/share/dh-subst/dh-subst should work, I
My point was that DRY implies that boilerplate should be avoided
as much as possible.
--
see shy jo
signature.asc
Description: Digital signature
Joey Hess writes:
> Gergely Nagy wrote:
>> For me, it does matter, I wouldn't go against your wishes if I can avoid
>> it. So, thank you! I'll go ahead with the separate package then.
>
> I will be happy to mention it in the appropriate place in debhelper(1)
> once it exists and some packages are
Gergely Nagy wrote:
> For me, it does matter, I wouldn't go against your wishes if I can avoid
> it. So, thank you! I'll go ahead with the separate package then.
I will be happy to mention it in the appropriate place in debhelper(1)
once it exists and some packages are using it. Let me know.
You
reassign 651393 wnpp
retitle 651393 ITP: dh-subst -- helper scripts for common executable debhelper
config file tasks
owner 651393 Gergely Nagy
thanks
Joey Hess writes:
> Gergely Nagy wrote:
>> Understandable.
>>
>> Would you find it acceptable to have a separate package, maintained by
>> som
Gergely Nagy wrote:
> Understandable.
>
> Would you find it acceptable to have a separate package, maintained by
> someone else, in which these scripts would be collected and maintained?
> (Something along the lines of dh-subst or similar, perhaps..)
My opinion does not matter in the least, but y
Joey Hess writes:
> Gergely Nagy wrote:
>> This way, the easy things would remain easy, just a
>> "#!/usr/lib/debhelper/dh_subst" away, and harder things would still be
>> possible. Everybody wins!
>
> While this is probably the best way to use executable config files (if
> it indeed makes sense
Gergely Nagy wrote:
> This way, the easy things would remain easy, just a
> "#!/usr/lib/debhelper/dh_subst" away, and harder things would still be
> possible. Everybody wins!
While this is probably the best way to use executable config files (if
it indeed makes sense to use them), I don't want to
Package: debhelper
Version: 8.9.12
Severity: wishlist
With the recent introduction of executable config files, there's a fear
that we could end up with a lot of very different implementations that
essentially accomplish the same thing.
To get ahead of that, I'm proposing a different option: a scr
8 matches
Mail list logo
