Hello Russ,
On Mon 13 May 2019 at 08:40PM -07, Russ Allbery wrote:
> That said, just as a matter of style and usability, we should describe the
> common case first and make it clear that one doesn't have to open up the
> details unless something isn't working right.
>
> [...]
>
> The path that, t
Sean Whitton writes:
> ISTM that dh is a special case because it basically tries to implement
> as much of Policy as is automatable, either in its own code, or by
> calling other tools in the right way.
> In particular, even if dh were used by every package, we would not want
> to replace all th
Hello Russ, Sam, others,
On Mon 13 May 2019 at 03:24PM -07, Russ Allbery wrote:
> The mandate of Policy is to specify the rules that packagers need to
> follow (plus the rules they should follow even if they're not required to
> follow) to integrate a package properly into Debian. In other words
Bill Allombert writes:
> Note that policy does not actually require that dpkg is used. Instead it
> goes to great length to describe what is the interface to dpkg that
> packages must relie on. This makes sense since this allow dpkg to evolve
> without breaking package policy compliance.
Persona
> "Bill" == Bill Allombert writes:
Bill> For package where upstream do not use the autotools, using dh
Bill> can be quite inconvenient compared to plain debhelper.
Bill> Cheers, -- Bill.
I've started the discussion on debian-devel about whether we want to
recommend/require dh.
> "Bill" == Bill Allombert writes:
Bill> On Sun, May 12, 2019 at 08:36:16AM -0400, Sam Hartman wrote:
>>
>> Now given our community it's entirely possible that the question
>> of whether it's a layering violation in our existing policy
>> architecture may influence whethe
On 5/1/19 10:29 PM, Bill Allombert wrote:
> For package where upstream do not use the autotools, using dh can be
> quite inconvenient compared to plain debhelper.
No, I don't think so. With every esoteic thing I've tried to pacakge, dh
was a good help. Overriding dh_auto_* when necessarry is eas
On Sun, May 12, 2019 at 08:36:16AM -0400, Sam Hartman wrote:
> > "Sean" == Sean Whitton writes:
>
> Sean> Hello,
> Sean> On Tue 30 Apr 2019 at 09:28AM -04, Sam Hartman wrote:
>
> >> I plan to start with the question of preferring dh as a package
> >> build tool. https://tren
> "Sean" == Sean Whitton writes:
Sean> Hello,
Sean> On Tue 30 Apr 2019 at 09:28AM -04, Sam Hartman wrote:
>> I plan to start with the question of preferring dh as a package
>> build tool. https://trends.debian.net/ has already added not
>> using dh as a "package smell" a
Hello,
On Tue 30 Apr 2019 at 04:39PM -07, Sean Whitton wrote:
> Policy currently documents an interface, and debhelper/dh is an
> implementation of large parts of that interface.
> [...]
Someone pointed out to me that in sending the e-mail to which I'm
replying, I violated Sam's request not to s
On Wed, May 01, 2019 at 10:29:26PM +0200, Bill Allombert wrote:
> For package where upstream do not use the autotools, using dh can be
> quite inconvenient compared to plain debhelper.
$ dh_auto_configure --list
autoconf GNU Autoconf (configure)
perl_build Perl Module::Build
On Tue, Apr 30, 2019 at 04:39:54PM -0700, Sean Whitton wrote:
> Hello,
>
> On Tue 30 Apr 2019 at 09:28AM -04, Sam Hartman wrote:
>
> > I plan to start with the question of preferring dh as a package build
> > tool. https://trends.debian.net/ has already added not using dh as a
> > "package smell
On 15389 March 1977, Sean Whitton wrote:
Thus, it would be something of a layering violation if the normative
part of Policy were to require or recommend using a particular tool to
implement its other normative content.
Perhaps, though, there's no way for Debian to implement such a change
oth
Hello,
On Tue 30 Apr 2019 at 09:28AM -04, Sam Hartman wrote:
> I plan to start with the question of preferring dh as a package build
> tool. https://trends.debian.net/ has already added not using dh as a
> "package smell" and so I'd like to validate whether the project agrees
> with that. I'll
14 matches
Mail list logo
