On Tue, Jun 04, 2019 at 03:06:13PM +, Thorsten Glaser wrote:
> Ian Jackson dixit:
> >But our one un-shirkable responsibility is that of creating an
> >environment where *others* can contribute.
@Ian: I really like that quote that could define a modernised Debian.
> Oh, sorry, but, I disagre
I think such a GR would be a collosal waste of time. This issue is
not important enough. In particular, because the consensus is *not*
GR's can be man made a collosal waste of time.
Well, a GR can be quick and it would help to know where people stand
instead of having a few vocal people decid
❦ 4 juin 2019 15:47 +01, Ian Jackson :
> If not, how do you think the question you pose should be answered ?
> Since it is a question of tradeoffs, with no definite right or wrong
> answer, perhaps we should hold a GR ? What do you think the result of
> such a GR would be ?
>
> I think such a G
Ian Jackson dixit:
>There is QA work on the many packages with no specific maintainer;
Sure, in that case I’ll have to take it over or deal with it.
>there are cross-archive campaigns such as reproducible builds,
>architecture support, init system diversity, i18n/l10n, and so on.
These are done
On Tue, Jun 04, 2019 at 02:27:03PM +, Thorsten Glaser wrote:
> No. A maintainer normally deals with their own packages, or with
> .dsc and debdiff, for NMU. (This is also an answer to the reply
> from wrar. Oh, jonas also said so, reloading the list index page.)
A maintainer normally deals with
Thorsten Glaser writes ("Re: Do we want to Require or Recommend DH"):
> No. A maintainer normally deals with their own packages, or with
> .dsc and debdiff, for NMU. (This is also an answer to the reply
> from wrar. Oh, jonas also said so, reloading the list index page.)
"
Sam Hartman dixit:
>He doesn't actually make that argument.
Hmm. Right, he doesn’t spell it out, but I got the impression.
Perhaps my reading was wrong.
>There are several reasons for not using dh we've already identified.
Sure… but…
>The fun factor is important.
… that.
>My reading of the com
On Tue, Jun 04, 2019 at 04:10:38PM +0200, Jonas Smedegaard wrote:
> > > I’d also throw in that monocultures are not good, and that people in
> > > general are happier when they aren’t forced into anything.
> > Yet people in general are also happier when they don't need to learn
> > all ways to do
> "Jonas" == Jonas Smedegaard writes:
Jonas> Quoting Andrey Rahmatullin (2019-06-04 15:58:33)
>> On Tue, Jun 04, 2019 at 01:37:46PM +, Thorsten Glaser wrote:
>> > I’d also throw in that monocultures are not good, and that
>> people in > general are happier when they aren’t
> "Thorsten" == Thorsten Glaser writes:
Thorsten> I would very much like to argue that not using dh is not a
Thorsten> bug, but Joey Hess, with his credentials ☺, did that
Thorsten> already (and much better than I could):
Thorsten> http://joeyh.name/blog/entry/80_percent/
He
Quoting Andrey Rahmatullin (2019-06-04 15:58:33)
> On Tue, Jun 04, 2019 at 01:37:46PM +, Thorsten Glaser wrote:
> > I’d also throw in that monocultures are not good, and that people in
> > general are happier when they aren’t forced into anything.
> Yet people in general are also happier when
On Tue, Jun 04, 2019 at 01:37:46PM +, Thorsten Glaser wrote:
> I’d also throw in that monocultures are not good, and that people
> in general are happier when they aren’t forced into anything.
Yet people in general are also happier when they don't need to learn all
ways to do something.
> Just
I would very much like to argue that not using dh is not a bug,
but Joey Hess, with his credentials ☺, did that already (and much
better than I could):
http://joeyh.name/blog/entry/80_percent/
tl;dr: dh started as 80% solution, it’s maybe an 96% solution now,
but it’s not intended as, and won’t b
Quoting Guillem Jover (2019-05-28 12:46:34)
> [dh] has proper documentation compared to cdbs which does not, which
> I think is the main reason I always found cdbs unappealing as you
> need to read its source code making its entire implementation its
> interface.
Another common technica
On Mon, 2019-05-13 at 08:33:44 -0400, Sam Hartman wrote:
> As promised, I'd like to start a discussion on whether we want to
> recommend using the dh command from debhelper as our preferred build
> system.
So, here's my take on this. I do use debhelper everywhere, I also use
dh mostly at work, and
On Tue, May 21, 2019 at 05:46:11AM -0400, Reinhard Tartler wrote:
> On Tue, May 21, 2019, 03:41 Vincent Bernat wrote:.
> > Is there an example of a package where dh cannot be used? Making 96% of
> > packages simpler and 4% of packages moderately more complex seems to be
> > a good argument to uni
Reinhard challenged me offlist to look at whether boxbackup would
actually be more maintainable with dh than with its current use of
debhelper.
Here are things I noticed that I wouldn't have to think about with dh.
The package may be correct, but if I were trying to maintain the package
I'd nee
Reinhard Tartler writes ("Re: Do we want to Require or Recommend DH"):
> I looked yesterday at the boxbackup source package and contemplated
> converting it to dh from debhelper. I decided to not, because I'm
> having a hard time seeing a significant simplification
> po
> "Reinhard" == Reinhard Tartler writes:
Reinhard>I looked yesterday at the boxbackup source package and
Reinhard> contemplated converting it to dh from debhelper. I decided
Reinhard> to not, because I'm having a hard time seeing a
Reinhard> significant simplification pote
On Tue, May 21, 2019, 03:41 Vincent Bernat wrote:.
>
> Is there an example of a package where dh cannot be used? Making 96% of
> packages simpler and 4% of packages moderately more complex seems to be
> a good argument to uniformize our packaging practices towards dh.
> --
> Use the fundamental c
On Tue, May 21, 2019 at 09:40:38AM +0200, Vincent Bernat wrote:
> ❦ 19 mai 2019 23:53 -04, Sam Hartman :
>
> > >> As promised, I'd like to start a discussion on whether we want to
> > >> recommend using the dh command from debhelper as our preferred
> > >> build system.
> >
> > Se
Quoting Vincent Bernat (2019-05-21 09:40:38)
> ❦ 19 mai 2019 23:53 -04, Sam Hartman :
>
> > >> As promised, I'd like to start a discussion on whether we
> > >> want to recommend using the dh command from debhelper as our
> > >> preferred build system.
> >
> > Sean> For those who haven't seen it
❦ 19 mai 2019 23:53 -04, Sam Hartman :
> >> As promised, I'd like to start a discussion on whether we want to
> >> recommend using the dh command from debhelper as our preferred
> >> build system.
>
> Sean> For those who haven't seen it, the original author of dh, Joey
> Sean>
> "Sean" == Sean Whitton writes:
Sean> Hello,
Sean> On Mon 13 May 2019 at 08:33AM -04, Sam Hartman wrote:
>> As promised, I'd like to start a discussion on whether we want to
>> recommend using the dh command from debhelper as our preferred
>> build system.
Sean> For
Hello,
On Mon 13 May 2019 at 08:33AM -04, Sam Hartman wrote:
> As promised, I'd like to start a discussion on whether we want to
> recommend using the dh command from debhelper as our preferred build
> system.
For those who haven't seen it, the original author of dh, Joey Hess, has
just publishe
Hi.
It looks like the discussion is simmering down.
My plan is to read over it all and come up with a consensus call
indicating areas where I believe we have consensus and what I think that
consensus is.
After I post that people will have an opportunity to comment on whether
I've judged conse
Hi Tollef,
On Wed, May 15, 2019 at 09:54:50PM +0200, Tollef Fog Heen wrote:
> ]] Andreas Tille
>
> > Can you give an example for a package that has a non-dh rules file
> > "working for years" that gives as a result a package with no lintian
> > warnings without changing this d/rules file?
>
> I
Hello,
On Tue 14 May 2019 at 12:30PM +01, Ian Jackson wrote:
> Sean Whitton writes ("Re: Do we want to Require or Recommend DH"):
>> I agree with Scott's emphasis on the distinction between new and
>> existing packages. Perhaps application of the distinction could
]] Andreas Tille
> Can you give an example for a package that has a non-dh rules file
> "working for years" that gives as a result a package with no lintian
> warnings without changing this d/rules file?
If you're talking about the binary package, fortunes-bofh-excuses. It
has some lintian warn
On Mon, May 13, 2019 at 05:58:47PM +0200, Thomas Goirand wrote:
Why would one want to switch that one to something else? The package,
basically, consists of a shell script and a man page only. The
minimalism of this package doesn't require an over-engineered dh
sequencer, does it?
I maintain on
On Tue, May 14, 2019 at 02:27:30PM +0800, Paul Wise wrote:
I think conversion to dh should only be done when doing hostile
hijacking of packages, salvaging packages, adopting packages,
orphaning packages or team/maintainer uploads and only if the person
doing the conversion builds the package twi
On Wed, 2019-05-15 at 09:18:26 +0100, Simon McVittie wrote:
> It uses dh_testroot, so it probably can't have Rules-Requires-Root: no,
> and needs to be built as (fake)root indefinitely - even though a package
> this simple can almost certainly be built correctly without fakeroot.
You've mention th
On Mon, 13 May 2019 at 17:58:47 +0200, Thomas Goirand wrote:
> Now, I have another example, which is quite the opposite one of what you
> gave as example:
>
> https://salsa.debian.org/openstack-team/debian/openstack-debian-images/blob/debian/stein/debian/rules
>
> Why would one want to switch tha
Simon McVittie schrieb:
> Packages using dh also make it a lot more straightforward to do
> archive-wide changes - similar to the benefit of using debhelper, but
> for changes that affect the "shape" of the build system rather than the
> details of individual steps. As a concrete example,
Or e.g.
On 5/13/19 11:31 PM, Thomas Goirand wrote:
>> - it's also simpler to understand.
>
> There, I don't agree. To fully understand how the dh sequencer works,
> one must first understand the 6 mandatory debian/rules targets, and how
> they are called.
You have to understand that in any case. Doesn
On Tue, 14 May 2019 11:11:46 +0300, Adrian Bunk wrote:
> On Mon, May 13, 2019 at 11:08:21PM +0200, gregor herrmann wrote:
> > On Mon, 13 May 2019 22:22:32 +0300, Adrian Bunk wrote:
> > > In my experience, keeping existing packages at exotic build systems or
> > > ancient dh compat levels causes f
On Tue, May 14, 2019 at 03:11:23PM +0100, Ian Jackson wrote:
>
> But my point is if you have a handwritten rules file it ends up so
> full of "obvious" boilerplate that it is difficult to see the trees
> for the wood, and there isn't anywhere obvious to put this kind of
> commentary. I think both
Holger Levsen writes ("Re: Do we want to Require or Recommend DH"):
> On Tue, May 14, 2019 at 12:30:02PM +0100, Ian Jackson wrote:
> > This provides an excellent
> > opportunity to leave a comment next to each weird thing explaining why
> > it's there.
> >
On Tue, 2019-05-14 at 12:54 +0200, Andreas Tille wrote:
> On Tue, May 14, 2019 at 10:38:06AM +0100, Ben Hutchings wrote:
> > On Tue, 2019-05-14 at 11:07 +0200, Andreas Tille wrote:
> > > Can you give an example for a package that has a non-dh rules file
> > > "working for years" that gives as a res
Le 14/05/2019 à 11:07, Andreas Tille a écrit :
> Can you give an example for a package that has a non-dh rules file
> "working for years" that gives as a result a package with no lintian
> warnings without changing this d/rules file?
Turns out I can't... I was thinking of some packages that I didn
On Tue, May 14, 2019 at 12:30:02PM +0100, Ian Jackson wrote:
> One thing that I found really good about dh is that you only have to
> write code about things that are unusual.
indeed.
> This provides an excellent
> opportunity to leave a comment next to each weird thing explaining why
> it's th
Sean Whitton writes ("Re: Do we want to Require or Recommend DH"):
> I agree with Scott's emphasis on the distinction between new and
> existing packages. Perhaps application of the distinction could be
> extended: perhaps there are other things that we could require
On Tue, May 14, 2019 at 10:38:06AM +0100, Ben Hutchings wrote:
> On Tue, 2019-05-14 at 11:07 +0200, Andreas Tille wrote:
> >
> > Can you give an example for a package that has a non-dh rules file
> > "working for years" that gives as a result a package with no lintian
> > warnings without changing
On Tue, May 14, 2019 at 10:27:45AM +0200, Johannes Schauer wrote:
> Quoting Adrian Bunk (2019-05-14 10:11:46)
> >
> > How well are you testing such conversions?
> > Based on work I've seen from you I'd guess your NMU would be better than
> > average. Unfortunately this is not generally true.
> >
On Tue, May 14, 2019 at 11:30:11AM +0200, Andreas Tille wrote:
> On Mon, May 13, 2019 at 10:22:32PM +0300, Adrian Bunk wrote:
> > On Mon, May 13, 2019 at 08:33:44AM -0400, Sam Hartman wrote:
> > >...
> > > Andreas Tille's explanation (quoted below) is typical of what I've heard
> > > in this area.
On Tue, 2019-05-14 at 11:07 +0200, Andreas Tille wrote:
> On Mon, May 13, 2019 at 04:22:49PM +0200, Thibaut Paumard wrote:
> > > Why Not Make this Change
> > >
> >
> > I would use dh for any new package and converting trivial packages is...
> > trivial. However converting
On Mon, May 13, 2019 at 10:22:32PM +0300, Adrian Bunk wrote:
> On Mon, May 13, 2019 at 08:33:44AM -0400, Sam Hartman wrote:
> >...
> > Andreas Tille's explanation (quoted below) is typical of what I've heard
> > in this area.
> >
> > >To come back
> > >to the question: I'm positively convinced tha
On Tue, May 14, 2019 at 09:10:04AM +, Holger Levsen wrote:
> On Tue, May 14, 2019 at 02:07:11PM +0500, Andrey Rahmatullin wrote:
> > One can go further and say that people uploading broken packages are the
> > actual problem. After all, we have several classes of bugs caused by
> > people uploa
On Tue, May 14, 2019 at 02:07:11PM +0500, Andrey Rahmatullin wrote:
> One can go further and say that people uploading broken packages are the
> actual problem. After all, we have several classes of bugs caused by
> people uploading .debs built in a broken env.
> Not sure if we can fix this and how
On Tue, May 14, 2019 at 11:11:46AM +0300, Adrian Bunk wrote:
> How well are you testing such conversions?
> Based on work I've seen from you I'd guess your NMU would be better than
> average. Unfortunately this is not generally true.
>
> Based on what enters the archive, "debdiff between old and
On Mon, May 13, 2019 at 04:22:49PM +0200, Thibaut Paumard wrote:
> > Why Not Make this Change
> >
>
> I would use dh for any new package and converting trivial packages is...
> trivial. However converting a package with a more convoluted rules files
> will take humanpower.
Quoting Adrian Bunk (2019-05-14 10:11:46)
> On Mon, May 13, 2019 at 11:08:21PM +0200, gregor herrmann wrote:
> > On Mon, 13 May 2019 22:22:32 +0300, Adrian Bunk wrote:
> >
> > > In my experience, keeping existing packages at exotic build systems or
> > > ancient dh compat levels causes fewer prob
On Mon, May 13, 2019 at 11:08:21PM +0200, gregor herrmann wrote:
> On Mon, 13 May 2019 22:22:32 +0300, Adrian Bunk wrote:
>
> > In my experience, keeping existing packages at exotic build systems or
> > ancient dh compat levels causes fewer problems than people trying to
> > change that just for
On 5/13/19 11:42 PM, Iustin Pop wrote:
> Very side note: why is that package a binary package instead of
> arch-indep, if it contains only a man page?
Not only a man page, but a shell script that either creates a Qcow2
image for OpenStack or installs Debian on bare-metal.
With the way it works, i
On Mon, May 13, 2019 at 8:34 PM Sam Hartman wrote:
> As promised, I'd like to start a discussion on whether we want to
> recommend using the dh command from debhelper as our preferred build
> system.
This is already the case AFAICT.
> But I think what we're really talking about is whether mainta
Hi,
On Mon, May 13, 2019 at 08:33:44AM -0400, Sam Hartman wrote:
> I'd like to call out one specific thing from Andreas's quote and the
> general argument. It's the belief that we've reached a point where in
> some cases uniformity is more important than maintainer preference.
I second this.
Wi
Hello,
On Mon 13 May 2019 at 04:32PM -04, Scott Kitterman wrote:
> I think for new packages (with the exception of new packages maintained in a
> team that has a different pattern), it's not unreasonable. When starting from
> scratch, dh is almost certainly no harder and usually easier than trad
On 2019-05-13 17:58:47, Thomas Goirand wrote:
> On 5/13/19 3:57 PM, Marco d'Itri wrote:
> > On May 13, Sam Hartman wrote:
> >
> >> As promised, I'd like to start a discussion on whether we want to
> >> recommend using the dh command from debhelper as our preferred build
> >> system.
> > I have al
On 5/13/19 6:28 PM, Sam Hartman wrote:
>> "Thomas" == Thomas Goirand writes:
>
> Thomas> Now, I have another example, which is quite the opposite one
> Thomas> of what you gave as example:
>
> Thomas>
> https://salsa.debian.org/openstack-team/debian/openstack-debian-images/blob/
Quoting Sam Hartman (2019-05-13 21:49:20)
> > "Holger" == Holger Levsen writes:
> Holger> On Mon, May 13, 2019 at 03:37:55PM -0400, Sam Hartman wrote:
> Bernd> gcc also needs a compiler to build - so I think it should be
> Bernd> safe to allow debhelper to build its package using
>
On Mon, 13 May 2019 22:22:32 +0300, Adrian Bunk wrote:
> In my experience, keeping existing packages at exotic build systems or
> ancient dh compat levels causes fewer problems than people trying to
> change that just for the sake of it.
In my experience ancient debian/rules runes are also a ca
On Monday, May 13, 2019 8:33:44 AM EDT Sam Hartman wrote:
> As promised, I'd like to start a discussion on whether we want to
> recommend using the dh command from debhelper as our preferred build
> system.
>
> As we can see on https://trends.debian.net/#build-systems a majority of
> packages alre
> "Holger" == Holger Levsen writes:
Holger> On Mon, May 13, 2019 at 03:37:55PM -0400, Sam Hartman wrote:
Bernd> gcc also needs a compiler to build - so I think it should be
Bernd> safe to allow debhelper to build its package using
Bernd> debhelper. Or am I missing something he
> "Bernd" == Bernd Zeimetz writes:
>> - build-depends of debhelper.
Bernd> gcc also needs a compiler to build - so I think it should be
Bernd> safe to allow debhelper to build its package using
Bernd> debhelper. Or am I missing something here?
If we reach consensus on the o
On Mon, May 13, 2019 at 03:37:55PM -0400, Sam Hartman wrote:
> Bernd> gcc also needs a compiler to build - so I think it should be
> Bernd> safe to allow debhelper to build its package using
> Bernd> debhelper. Or am I missing something here?
> If we reach consensus on the overall idea,
On 5/13/19 3:39 PM, Holger Levsen wrote:
> On Mon, May 13, 2019 at 08:33:44AM -0400, Sam Hartman wrote:
>> Today at least I don't think we're talking about making not using dh an
>> RC bug. It would not make a lot of sense to me to start there.
>
> indeed. using dh should currently be a "should"
On Mon, May 13, 2019 at 08:33:44AM -0400, Sam Hartman wrote:
>...
> Andreas Tille's explanation (quoted below) is typical of what I've heard
> in this area.
>
> >To come back
> >to the question: I'm positively convinced that we should strive to
> >unify our packaging as much as possible and in ter
On Mon, May 13, 2019 at 05:58:47PM +0200, Thomas Goirand wrote:
> https://salsa.debian.org/openstack-team/debian/openstack-debian-images/blob/debian/stein/debian/rules
> Why would one want to switch that one to something else?
- because it makes archive wide changes a lot easier.
- it's also simp
On Mon, 13 May 2019 at 15:57:34 +0200, Marco d'Itri wrote:
> I have already asked this last time, but nobody answered.
> I use debhelper in all of my packages but I have never switched to dh:
> why should I bother?
Here are some reasons you might want to consider.
When modifying those packages,
On 13.05.19 15:39, Holger Levsen wrote:
Maybe we could also make the "should" stronger:
- new packages (except if they are ment to become build-depends of
debhelper)*must* either use dh or cdbs.
- old packages should be switched to dh (or cdbs).
And then turn this "should" into a "must" for
> "Thomas" == Thomas Goirand writes:
Thomas> Now, I have another example, which is quite the opposite one
Thomas> of what you gave as example:
Thomas>
https://salsa.debian.org/openstack-team/debian/openstack-debian-images/blob/debian/stein/debian/rules
Thomas> Why would one
Hi Ben,
On 2019-05-13 15:10, Ben Hutchings wrote:
> On Mon, 2019-05-13 at 06:08 -0700, Mo Zhou wrote:
> [...]
>> In brief:
>> * if maintained by person: no restriction, given that
>> the maintainer is not MIA
>> * if team-maintained: recommend dh
>
> I would suggest almost the opposite. If a t
On 5/13/19 3:57 PM, Marco d'Itri wrote:
> On May 13, Sam Hartman wrote:
>
>> As promised, I'd like to start a discussion on whether we want to
>> recommend using the dh command from debhelper as our preferred build
>> system.
> I have already asked this last time, but nobody answered.
> I use deb
On Mon, 13 May 2019, 4:43 pm Thibaut Paumard, wrote:
> However converting a package with a more convoluted rules files
> will take humanpower. While it may be justified to convert a mildly
> complex rules file on a package that has some activity, I don't think I
> would invest those resources to
Ben Hutchings wrote:
>
>On Mon, 2019-05-13 at 06:08 -0700, Mo Zhou wrote:
>[...]
>> In brief:
>> * if maintained by person: no restriction, given that
>> the maintainer is not MIA
>> * if team-maintained: recommend dh
>
>I would suggest almost the opposite. If a team is happy to use an
>unusual
On Mon, 2019-05-13 at 06:08 -0700, Mo Zhou wrote:
[...]
> In brief:
> * if maintained by person: no restriction, given that
> the maintainer is not MIA
> * if team-maintained: recommend dh
I would suggest almost the opposite. If a team is happy to use an
unusual tool, that's OK because there is
Hi,
Le 13/05/2019 à 14:33, Sam Hartman a écrit :
> Why Would we Want This?
> ===
dh is gret for the vast majority of packages. Whenever your rules files
ends up with the simple catch all line, plus a couple of auto_something
overrides, its probably the best solution.
For com
On May 13, Sam Hartman wrote:
> As promised, I'd like to start a discussion on whether we want to
> recommend using the dh command from debhelper as our preferred build
> system.
I have already asked this last time, but nobody answered.
I use debhelper in all of my packages but I have never switc
On Mon, May 13, 2019 at 08:33:44AM -0400, Sam Hartman wrote:
> Today at least I don't think we're talking about making not using dh an
> RC bug. It would not make a lot of sense to me to start there.
indeed. using dh should currently be a "should" in policy, with two
exceptions:
- packages using
Hi Sam,
On 2019-05-13 12:33, Sam Hartman wrote:
> The New Maintainer's Guide [1] already is based around debhelper and dh
> and effectively recommends it strongly. So it wouldn't mean that.
>
> [1]: https://www.debian.org/doc/manuals/maint-guide/
Several years ago I nearly re-translated maint
80 matches
Mail list logo
