Do we want to Require or Recommend DH

classic Classic list List threaded Threaded
116 messages Options
1234 ... 6
Reply | Threaded
Open this post in threaded view
|

Do we want to Require or Recommend DH

Sam Hartman-5

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 already use dh.  So what would it mean to recommend dh?

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/

I guess at a simplest level, this would be validating the assumption
that Lucas made behind trends.debian.net that not using dh is a "package
smell," that maintainers should think about fixing.

But I think what we're really talking about is whether maintainers
should be expected to apply well-written patches to convert a package to
using dh.  That is, is not using dh a bug.

And at some level I think we're asking whether it is appropriate to NMU
a package to convert it to dh.


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.

Exceptions
==========

Even if we do decide that not using dh is generally a bug, there are
doubtless some exceptions.  If I remember correctly at least one of the
language-specific packaging approaches is based around something else.

There may be some classes of packages where dh doesn't make sense today.

As part of this discussion I hope we will collect a list of exceptions
where dh is not the right answer today.

Why Would we Want This?
=======================

So, first, a lot of people have argued that dh makes packaging simpler.
I've certainly found that to be true and use dh for any new package I
make.

That alone might be an argument for no dh being a package smell, but
probably not a good argument for making not using dh a bug.  If dh makes
your packaging simpler, that alone is probably sufficient motivation to
adopt it where appropriate.

There's another argument though.  Using dh might make things easier for
others making changes to your packages.  It makes it easier for us to
apply changes in things like how init scripts are called across the
archive.

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 terms of d/rules file dh
>is obviously the default we should pick.  I'd go that far that lintian
>should issue some warning at "pedantic" level if there is no comment:
>"I'm not using dh because ... ".  In other words:  Use dh in debian/rules
>should make it into policy.

>The rationale is that dh makes it extremely easy to understand other
>d/rules files.  Specifically in freeze like now it is easy to touch
>other peoples packages (just done this several times in the last weeks
>and luckily close to all used dh).  Its the point of teamwork (and I
>consider all people touching official Debian packages as a team) to make
>things simple for team mates.  I consider it a valid request to every
>single maintainer to respect that other people have good reasons to
>change her/his package.


Evolution Towards a Team
========================

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.

If true, that would be a big change for our community.  We've spent many
years making it easy for maintainers to have a great deal of autonomy.

I don't see that going away, but Andreas and others seem to be arguing
that once we've found a good solution we should encourage uniform
adoption to make it easier when we have to work on others' packages.

Why Not Make this Change
========================

The biggest argument I've heard against changes in this area is that
moving towards dh and debhelper will introduce bugs.
Like any significant change it requires effort both for development and
for testing.

One maintainer claimed that even if someone else wrote the patch it
wasn't worth their effort to validate for a package where the existing
build system was already working.

Your Thoughts
=============

so, what do you think?

I'll start with a general discussion but unless the answers are obvious
follow up with some specific questions in a few days.

Thanks for helping us explore this issue,

--Sam

signature.asc (497 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Do we want to Require or Recommend DH

Mo Zhou
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-guide into Simplified
Chinese
due to it's severely outdated .po strings. That means, all I know about
Debian
packaging is based on Joey's debhelper. This will be the same to
newcomers
who start with a debhelper based document.

> using dh.  That is, is not using dh a bug.
> [omitted]
> And at some level I think we're asking whether it is appropriate to NMU
> a package to convert it to dh.
> [omitted]
> 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.
> [omitted]
> so, what do you think?

Keep the old stuff as is if they don't break and don't introduce
maintainance issue. Anything related to diversity, including packaging
helper diversity, should be carefully considered in this community.
We still remember how people react on the systemd v.s. sysv discussion.
So I respect the minority-tools such as cdbs, or any alike, because
there are still people who like them and I respect these people.

That said, I suggest that we recommend team-maintained packages to be
debhelper(dh)-based. That's because not many people can understand
minority helpers such as cdbs. For example, when I see a broken
team-maintained packaging that is written in cdbs, I'll simply
give up trying to understand anything.

In brief:
* if maintained by person: no restriction, given that
  the maintainer is not MIA
* if team-maintained: recommend dh

Reply | Threaded
Open this post in threaded view
|

Re: Do we want to Require or Recommend DH

Holger Levsen-2
In reply to this post by Sam Hartman-5
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 cdbs. cdbs has features dh doesnt have and I dont think
  it's wrong to use cdbs. (Although I don't recommend it...)
- build-depends of debhelper.

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 bookworm (and thus make it
RC then as well).


--
tschau,
        Holger

-------------------------------------------------------------------------------
               holger@(debian|reproducible-builds|layer-acht).org
       PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C

Dance like no one's watching. Encrypt like everyone is.

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Do we want to Require or Recommend DH

Marco d'Itri
In reply to this post by Sam Hartman-5
On May 13, Sam Hartman <[hidden email]> 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 switched to dh:
why should I bother?
"Everybody is doing this" is not much of an argument.

Would dh really make a debian/rules file like these simpler to
understand? Can somebody try to win me over with a patch? :-)

https://salsa.debian.org/md/inn2/blob/master/debian/rules
https://salsa.debian.org/md/kmod/blob/master/debian/rules

> There's another argument though.  Using dh might make things easier for
> others making changes to your packages.  It makes it easier for us to
But would it really be much easier than debhelper?

> The biggest argument I've heard against changes in this area is that
> moving towards dh and debhelper will introduce bugs.
Everything introduces bugs, but I have never considered this a valid
reason to stop improving software.

--
ciao,
Marco

signature.asc (673 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Do we want to Require or Recommend DH

Thibaut Paumard-8
In reply to this post by Sam Hartman-5
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 complex cases, dh is not better or worse than anything else. It does
not make it more easy (or more difficult) to write or read a complex
rules file.

> 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. 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 convert a package that's been working
for years without anyone touching it's rules files.

So I would tend to treat this change as any other (e.g. the quilt
format): on a best effort basis, whenever you have to touch a rules
file, consider switching. I would really not go so far as to make
working software RC buggy just because it uses a style that was once the
recommended one and stuck to it.

Kind regards, Thibaut.


signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Do we want to Require or Recommend DH

Ben Hutchings-3
In reply to this post by Mo Zhou
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 (usually) at least one team
member available to work on the package.  But when there is a single
maintainer, it is more likely that the maintainer will be absent at
some time (even though they are not completely MIA), and NMUs will be
required.  Then it's important that other random developers can do the
NMU.

Ben.

--
Ben Hutchings
For every complex problem
there is a solution that is simple, neat, and wrong.



signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Do we want to Require or Recommend DH

Steve McIntyre
In reply to this post by Mo Zhou
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 tool, that's OK because there is (usually) at least one team
>member available to work on the package.  But when there is a single
>maintainer, it is more likely that the maintainer will be absent at
>some time (even though they are not completely MIA), and NMUs will be
>required.  Then it's important that other random developers can do the
>NMU.

I was thinking just the same, yes. From experience at a lot of BSPs
(for example), it's most often the obscure-workflow single-maintainer
packages that take the most effort to work on.

--
Steve McIntyre, Cambridge, UK.                                [hidden email]
  Armed with "Valor": "Centurion" represents quality of Discipline,
  Honor, Integrity and Loyalty. Now you don't have to be a Caesar to
  concord the digital world while feeling safe and proud.

Reply | Threaded
Open this post in threaded view
|

Re: Do we want to Require or Recommend DH

Mattia Rizzolo-5
In reply to this post by Thibaut Paumard-8
On Mon, 13 May 2019, 4:43 pm Thibaut Paumard, <[hidden email]> 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 convert a package that's been working
for years without anyone touching it's rules files.

In the past I took the approach that nearly anything that required me to tweak it's build system more than flipping configure switches meant that the upstream build system needed _something_ to be more clever and do what I wanted by itself.  That lead me to write patches that were then gladly accepted and therefore further simplified the rules file even more.

So I would tend to treat this change as any other (e.g. the quilt
format): on a best effort basis, whenever you have to touch a rules
file, consider switching

I did just that on several NMUs that I did: I needed to mildly touch the rules file, it proved easier to just rewrite it using dh :>

Reply | Threaded
Open this post in threaded view
|

Re: Do we want to Require or Recommend DH

Thomas Goirand-3
In reply to this post by Marco d'Itri
On 5/13/19 3:57 PM, Marco d'Itri wrote:

> On May 13, Sam Hartman <[hidden email]> 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 switched to dh:
> why should I bother?
> "Everybody is doing this" is not much of an argument.
>
> Would dh really make a debian/rules file like these simpler to
> understand? Can somebody try to win me over with a patch? :-)
>
> https://salsa.debian.org/md/inn2/blob/master/debian/rules

Without looking much, without checking if the package even builds,
here's a possible result:

https://salsa.debian.org/zigo/inn2/blob/master/debian/rules

Admittedly, I haven't understood all of the hacks you did (what's the
$(no_package) thing for?).

It's only 15 lines shorter, but that's not the point. The point is that
it only declares things you are not doing like everyone else.

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 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'm happy the way the package is, and I don't think
I'd switch to the dh sequencer *UNLESS* someone has a better argument
than "it's new", or "debian/rules will be smaller", or even "it's going
to evolve without you even noticing it" (which is more scary than
anything else, which is IMO one of the defects of the dh sequencer).

Cheers,

Thomas Goirand (zigo)

Reply | Threaded
Open this post in threaded view
|

Re: Do we want to Require or Recommend DH

Mo Zhou
In reply to this post by Ben Hutchings-3
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 team is happy to use an
> unusual tool, that's OK because there is (usually) at least one team
> member available to work on the package.  But when there is a single
> maintainer, it is more likely that the maintainer will be absent at
> some time (even though they are not completely MIA), and NMUs will be
> required.  Then it's important that other random developers can do the
> NMU.

The argument is fair enough from a different view point from mine.
However:

Assume that we only target on "maximizing our chance to survive when
an unusual package goes wrong", then clearly enforcing debhelper
everywhere is the best choice. The probability that a random Debian
Developer could not fix the unusual thing is approximately 1.
For any maintenance work, whatever personally maintained or team
maintained, the best choice to maximize the probability that "another
random DD can help original maintainer fix some issue", is to enforce
what most people use. Further more, the probability that "there are
more than one people in a team that understands the same unusual
thing" is exponentially less than the probability that "only one
member understands it". This is the mathematical/statistical fact.

My view point doesn't start from the cruel fact, but the original
maintainer's will. Given that

* The original maintainer understands what maintaing package under
  personal name instead of a team means.
* The original maintainer understands what utilizing something
  unusual means to collaboration.
* The original maintainer is not MIA.

Then a personally maintained unusual package means that the
original maintainer had fun in his/her unusual choices, and
had a strong reason in doing something unusual.

My updated suggestions:

* if personally maintained:
      if MIA:
          One can overwrite the unusual stuff through ITS
      else:
          We respect the original maintainer's joyfulness.
          Everybody has (initiative or passive) off-line time.
          Short absence should not be the reason to override
          original maintainer's will.
* if team-maintained:
       We do things democratically. When there is no preference
       on unusual stuff among team members, we recommend/enforce
       debhelper generally, in order to maximize our chance to
       survive when something goes wrong.

Reply | Threaded
Open this post in threaded view
|

Cdbs Features

Sam Hartman-3
In reply to this post by Holger Levsen-2
>>>>> "Holger" == Holger Levsen <[hidden email]> writes:
    Holger> - packages using cdbs. cdbs has features dh doesnt have and
    Holger> I dont think it's wrong to use cdbs. (

Just for my information, what are the big features cdbs has that dh does
not?

Reply | Threaded
Open this post in threaded view
|

Re: Do we want to Require or Recommend DH

Sam Hartman-3
In reply to this post by Thomas Goirand-3
>>>>> "Thomas" == Thomas Goirand <[hidden email]> 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 want to switch that one to something else? The
    Thomas> package, basically, consists of a shell script and a man
    Thomas> page only. The minimalism of this package doesn't require an
    Thomas> over-engineered dh sequencer, does it? I'm happy the way the
    Thomas> package is, and I don't think I'd switch to the dh sequencer
    Thomas> *UNLESS* someone has a better argument than "it's new", or
    Thomas> "debian/rules will be smaller", or even "it's going to
    Thomas> evolve without you even noticing it" (which is more scary
    Thomas> than anything else, which is IMO one of the defects of the
    Thomas> dh sequencer).

Could you make an attempt at articulating this as an exception?
That is, openstack-debian-images should not  use dh because <something
generic that could be evaluated against other packages>

Reply | Threaded
Open this post in threaded view
|

Re: Do we want to Require or Recommend DH

Alf Gaida
In reply to this post by Holger Levsen-2
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 bookworm (and thus make it
> RC then as well).

Thanks Holger, couln't write it better, fully aggree.

Cheers Alf

Reply | Threaded
Open this post in threaded view
|

Re: Do we want to Require or Recommend DH

Simon McVittie-7
In reply to this post by Marco d'Itri
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, a contributor (perhaps a NMUer, or perhaps
your future self) will have to think about questions like these, which
they wouldn't have to do if you were using dh:

- is this package invoking the various dh_foo helpers in the right order?
  (e.g. if dh_one needs to be invoked before dh_two, not all packages get
  this right, but a dh sequence always will)

- is there a missing dh_foo helper that would be advantageous to call, but
  has not been called?
  (e.g. if a future debhelper version adds a dh_sha256sums that should
  be invoked before or after dh_md5sums, your packages won't benefit from
  it automatically)

- is everything that this package does still necessary?
  (e.g. as far as I can see, inn2 genuinely needs to be (fake)root so
  it can chown things to root:news; kmod probably doesn't; but kmod is
  calling dh_testroot, so it needs to be built under fakeroot anyway,
  which makes the build more precarious by introducing an unnecessary
  layer of LD_PRELOAD hacks)

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, in sufficiently
recent compat levels, dh ensures that you don't need the scaffolding
for making binary-arch, binary-indep, binary, build, etc. correctly
interdependent, which would have saved you some work when build-arch
and build-indep became mandatory targets, and more importantly would
have made sure these packages didn't block our progress towards being
able to make those targets mandatory.

Using debhelper build systems (dh_auto_whatever), instead of invoking
configure and make or their CMake/Meson/etc. equivalents yourself,
also has some important benefits for archive-wide changes. People who
are cross-compiling Debian have already gained a lot from this: they
can change how debhelper invokes (for example) Autotools or CMake,
in one place, and have it applied to all Autotools or CMake packages,
either immediately or the next time that package's maintainer bumps
compat level. As a result of this, the patches attached to a lot of
FTCBFS bug reports are of the form "stop calling configure, instead
call dh_auto_configure", which does the right thing without adding a
lot of open-coded logic to the package.

    smcv

Reply | Threaded
Open this post in threaded view
|

Re: Do we want to Require or Recommend DH

Holger Levsen-2
In reply to this post by Thomas Goirand-3
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 simpler to understand.


--
tschau,
        Holger

-------------------------------------------------------------------------------
               holger@(debian|reproducible-builds|layer-acht).org
       PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Do we want to Require or Recommend DH

Adrian Bunk-3
In reply to this post by Sam Hartman-5
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 terms of d/rules file dh
> >is obviously the default we should pick.  I'd go that far that lintian
> >should issue some warning at "pedantic" level if there is no comment:
> >"I'm not using dh because ... ".  In other words:  Use dh in debian/rules
> >should make it into policy.
>
> >The rationale is that dh makes it extremely easy to understand other
> >d/rules files.  Specifically in freeze like now it is easy to touch
> >other peoples packages (just done this several times in the last weeks
> >and luckily close to all used dh).  Its the point of teamwork (and I
> >consider all people touching official Debian packages as a team) to make
> >things simple for team mates.  I consider it a valid request to every
> >single maintainer to respect that other people have good reasons to
> >change her/his package.
>...

Based on this rationale, Andreas should stop using d-shlibs.

Weird tools on top of dh are not that different from using a weird
buildsystem when debugging other peoples packages, and d-shlibs is
something I've seen involved in bugs more than once.

>...
> As we can see on https://trends.debian.net/#build-systems a majority of
> packages already use dh.  So what would it mean to recommend dh?
>...
> As part of this discussion I hope we will collect a list of exceptions
> where dh is not the right answer today.
>...

What is actually the problem that needs legislating here?

For any newly packaged (and often also adopted) package that can
be packaged with the trivial dh 3-liner this is already being done,
with exceptions within the margin of error.

When you debug for the first time a non-trivial problem in a complex
package like src:gcc-8 or in a package in an ecosystem like Haskell you
can easily spend hours just for figuring out what is actually going on
or how to pass additional flags. Whether or not the build machinery is
using dh is not a big difference when you have to understand what is
actually going on.

>...
> And at some level I think we're asking whether it is appropriate to NMU
> a package to convert it to dh.
>...

Common causes of broken packages in the archive include:
- dh compat level bumps
- conversion of debhelper using packages to the short dh form
- conversion from other build systems to dh

It is already a real problem when maintainers are bumping dh compat
levels without checking very thoroughly before uploading that this
didn't cause any regression - a dh compat level bump is a breaking
change and should not be done without due diligence.

And we do get broken packages packages uploaded where the NMU
of a build system change (e.g. cdbs to dh) resulted in an empty
package - whoever uploaded such a package clearly didn't even
do basic checks.

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.

> --Sam

cu
Adrian

--

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Reply | Threaded
Open this post in threaded view
|

Re: Do we want to Require or Recommend DH

Bernd Zeimetz
In reply to this post by Holger Levsen-2
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" in policy, with two
> exceptions:
>
> - packages using cdbs. cdbs has features dh doesnt have and I dont think
>   it's wrong to use cdbs. (Although I don't recommend it...)

If there is really something left where cdbs is better than dh, then
this should be fixed in dh instead.

> - build-depends of debhelper.

gcc also needs a compiler to build - so I think it should be safe to
allow debhelper to build its package using debhelper. Or am I missing
something here?

> 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 bookworm (and thus make it
> RC then as well).

I strongly second this, although I'm not sure if cdbs should be involed
or not, but yes, dh should be used these days and turning that into a
"must" should happen sonner than later in my opinion.



--
 Bernd Zeimetz                            Debian GNU/Linux Developer
 http://bzed.de                                http://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F


signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Do we want to Require or Recommend DH

Sam Hartman-3
>>>>> "Bernd" == Bernd Zeimetz <[hidden email]> 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 overall idea, I was planning to ask the
debhelper maintainers whether they thought they needed an exception for
build-depends of debhelper.
Unless you think you have special knowledge there, let's assume we can
handle that question as part of working through details.

Reply | Threaded
Open this post in threaded view
|

Re: Do we want to Require or Recommend DH

Holger Levsen-2
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, I was planning to ask the
> debhelper maintainers whether they thought they needed an exception for
> build-depends of debhelper.
> Unless you think you have special knowledge there, let's assume we can
> handle that question as part of working through details.

I think being bootstrappable(.org) is a very worthwhile feature, so
please let's not make this harder than it already is.

(If you haven't, please visit that URL with a browser.)


--
tschau,
        Holger

-------------------------------------------------------------------------------
               holger@(debian|reproducible-builds|layer-acht).org
       PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C

Dance like no one's watching. Encrypt like everyone is.

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Do we want to Require or Recommend DH

Sam Hartman-3
>>>>> "Holger" == Holger Levsen <[hidden email]> 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 here?
    >> If we reach consensus on the overall idea, I was planning to ask
    >> the debhelper maintainers whether they thought they needed an
    >> exception for build-depends of debhelper.  Unless you think you
    >> have special knowledge there, let's assume we can handle that
    >> question as part of working through details.

    Holger> I think being bootstrappable(.org) is a very worthwhile
    Holger> feature, so please let's not make this harder than it
    Holger> already is.

Debhelper is arch all and because of its implementation its "opaque"
binaries aren't very opaque as these things go.
I think that the debhelper maintainers are aware of the issues of
bootstrappability and can make an informed decision here.

I'll be shocked if there's not already a cycle involving building dpkg
requiring a build of debhelper as an example.


--Sam

1234 ... 6