Re: Do we want to Require or Recommend DH
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
Re: Do we want to Require or Recommend DH
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 Description: PGP signature
Re: Do we want to Require or Recommend DH
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 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 Description: PGP signature
Re: Do we want to Require or Recommend DH
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 Description: OpenPGP digital signature
Re: Do we want to Require or Recommend DH
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 Description: This is a digitally signed message part
Re: Do we want to Require or Recommend DH
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.st...@einval.com 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.
Re: Do we want to Require or Recommend DH
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 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 :> > >
Re: Do we want to Require or Recommend DH
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 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)
Re: Do we want to Require or Recommend DH
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.
Re: Do we want to Require or Recommend DH
> "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 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
Re: Do we want to Require or Recommend DH
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
Re: Do we want to Require or Recommend DH
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
Re: Do we want to Require or Recommend DH
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 Description: PGP signature
Re: Do we want to Require or Recommend DH
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
Re: Do we want to Require or Recommend DH
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 ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F signature.asc Description: OpenPGP digital signature
Re: Do we want to Require or Recommend DH
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 Description: PGP signature
Re: Do we want to Require or Recommend DH
> "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 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.
Re: Do we want to Require or Recommend DH
> "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 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
Re: Do we want to Require or Recommend DH
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 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. Absolutely not. A likely bug inducing drive-by NMU is not helpful. > > 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 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 almos
Re: Do we want to Require or Recommend DH
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 cause for repeated RC bugs and the need for NMUs. Real life example: https://tracker.debian.org/media/packages/libm/libmp3-info-perl/changelog-1.24-1.2 Both RC bugs wouldn't have happened with dh(1); and the second NMU wouldn't have been necessary if I had switched to dh(1) in the first one. Cheers, gregor -- .''`. https://info.comodo.priv.at -- Debian Developer https://www.debian.org : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06 `. `' Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe `- NP: Rolling Stones signature.asc Description: Digital Signature
Re: Do we want to Require or Recommend DH
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/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? I agree this package is probably an exception. On 5/13/19 7:42 PM, Holger Levsen wrote: > - because it makes archive wide changes a lot easier. Right. Though I very much doubt this super-simple package will miss any archive-wide change applied through modifying the way dh sequences things. If this happens, it will mean we're over-engineering things. > - 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. dh will hide everything. It isn't simpler, it *LOOKS* simpler, but it's a way more complex. When dh appeared, it took me months to accept it, because I didn't like it was hiding everything. I appreciate why it's done, and I do use dh in most of my packages, but it's still the case that I would prefer if it wasn't hiding everything. Cheers, Thomas Goirand (zigo)
Re: Do we want to Require or Recommend DH
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 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). This example is indeed interesting, but IMO for the opposite reason. The last commit on this file was to fix #853907 which is about the intricacies of exactly which targets to call in which sequence for the package type. Which dh avoids, because it has logic to do things rather than require the human to write the exact code needed - since we don't have (or didn't have at that time) good enough pre-upload tests. So in this case, wouldn't dh have completely avoided the bug? Very side note: why is that package a binary package instead of arch-indep, if it contains only a man page? regards, iustin signature.asc Description: PGP signature
Re: Do we want to Require or Recommend DH
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 traditional > debhelper or other approaches. > > For existing packages, not so much. There are probably packages left that > would be trivial to convert, but I expect that most of those have been taken > care of already. For complex packages, this can be really hard to get right. > In the experiences I've had, converting packages that I maintain and have a > great deal of familiarity with is still fraught with error. > > For really complex packages, they are going to be hard for someone not > familiar with the package to modify regardless of dh/debhelper. My guess is > that if we try and push this direction the effort will mostly be spent where > there is the least potential for gain and the most risk of regressions. > > For improvement of existing packages, I think there are better things to > expend resources on. 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 of new packages, while creating no expectation that these requirements be met of older packages. In general, if a policy requirement or convention should apply to new packages, then it should apply to existing packages, too. But specifically where applying the requirement to an existing package is hugely more work than applying it to a new package, perhaps the requirement ought to be limited to new packages alone. -- Sean Whitton signature.asc Description: PGP signature
Re: Do we want to Require or Recommend DH
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. With my cross/bootstrap maintainer hat (it's not an official hat, but I think I have this hat at this point in time), I can say that this uniformity is key to making archive-wide change feasible. During my work on cross/bootstrap, I've sent more than 1500 patches. I guess that almost half of those were one of: * use dh_auto_configure * use dh_auto_build * don't strip before dh_strip * bump debhelper compat level In other words, a significant chunk of packages would have just worked had they used debhelper. On top of that, I observed that a fair number of broken packages had one other bug "please make the build reproducible". I would be surprised if the reproducible experience is much different from mine. Maintainer preference has a real cost to the project and that cost needs to be measured in weeks or months, not minutes. Due to the added friction I've generally avoided fixing packages that were using cdbs or no debhelper at all. My personal view is that we should stop using cdbs entirely, but I'm not sure that consensus is achievable on this point. This is a statement towards the general direction. I have no good idea how to turn that into policy or the like. Given my little experience with Haskell packages, I would exempt the haskell ecosystem from a rule. Hope this helps as a data point Helmut
Re: Do we want to Require or Recommend DH
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 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. I don't think these are appropriate. 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 twice (with and without dh), inspects the resulting changes to the binary packages with diffoscope and is confident that each change is appropriate. > Exceptions > == I think we should allow the cdbs maintainer to use cdbs instead of dh in their packages :) > so, what do you think? I don't think there is any way to require packages use dh, unless you want to forcibly remove/orphan packages or remove maintainers that won't use dh? I think that we should encourage experimentation with better alternatives to dh, such as if someone wanted to revive the efforts to build Debian packages using Gentoo's ebuild framework. http://penta.debconf.org/dc7_schedule/events/69.en.html -- bye, pabs https://wiki.debian.org/PaulWise
Re: Do we want to Require or Recommend DH
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, it only makes sense on the listed architecture where it has been tested. I wish there was a possibility to say "it's arch all, but only works on these", but in Debian, we can't. Cheers, Thomas Goirand (zigo)
Re: Do we want to Require or Recommend DH
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 the sake of it. > > In my experience ancient debian/rules runes are also a cause for > repeated RC bugs and the need for NMUs. > > Real life example: > https://tracker.debian.org/media/packages/libm/libmp3-info-perl/changelog-1.24-1.2 > > Both RC bugs wouldn't have happened with dh(1); and the second NMU > wouldn't have been necessary if I had switched to dh(1) in the first > one. 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 new package" already seems to be something that many people are not doing - then cleaning up after mass-NMUs would be much work. I have even seen maintainers blindly replacing a complex old debian/rules with the dh 3-liner, and all the bugfixes and workarounds in the old one were bugs again. To show the quantitative side of my argument: The default change to parallel building in dh compat 10 alone has caused a three digit number of RC bugs, popping up at a pace of 1-2 RC bugs per week for several years. The problem is that anything that works for only 99% of all packages results in such a high number of new bugs. Parallel build bugs slipping through an upload can happen, but maintainers not going through the upgrading checklist and running debdiff between old and new packages as well as testing them when doing dh compat bumps is harder to excuse - and in practice this does happen. There is no perfect solution here and I also get your point, what should be taken into consideration is that there is a tradeoff between the benefits and the regressions of breaking changes like dh compat bumps or even conversions to dh. In my experience people are already pushing too much towards "use dh with latest compat" in existing packages, and it would be better to slow that down rather than accelerate it even further. > Cheers, > gregor 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
Re: Do we want to Require or Recommend DH
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 problems than people trying to > > > change that just for the sake of it. > > > > In my experience ancient debian/rules runes are also a cause for > > repeated RC bugs and the need for NMUs. > > > > Real life example: > > https://tracker.debian.org/media/packages/libm/libmp3-info-perl/changelog-1.24-1.2 > > > > Both RC bugs wouldn't have happened with dh(1); and the second NMU > > wouldn't have been necessary if I had switched to dh(1) in the first > > one. > > 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 new package" > already seems to be something that many people are not doing - then > cleaning up after mass-NMUs would be much work. > > I have even seen maintainers blindly replacing a complex old > debian/rules with the dh 3-liner, and all the bugfixes and > workarounds in the old one were bugs again. > > To show the quantitative side of my argument: > > The default change to parallel building in dh compat 10 alone has caused > a three digit number of RC bugs, popping up at a pace of 1-2 RC bugs > per week for several years. > > The problem is that anything that works for only 99% of all packages > results in such a high number of new bugs. > > Parallel build bugs slipping through an upload can happen, > but maintainers not going through the upgrading checklist > and running debdiff between old and new packages as well > as testing them when doing dh compat bumps is harder to > excuse - and in practice this does happen. > > There is no perfect solution here What makes reproducible-builds not the perfect fit for this? Whenever I converted a package to dh or bumped debhelper compat level, I always checked whether the produced binaries were bit-by-bit identical to the ones before. Are there many errors that I would be missing by relying on reproducibility results? Thanks! cheers, josch signature.asc Description: signature
Re: Do we want to Require or Recommend DH
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 new package" > already seems to be something that many people are not doing - then > cleaning up after mass-NMUs would be much work. > > I have even seen maintainers blindly replacing a complex old > debian/rules with the dh 3-liner, and all the bugfixes and > workarounds in the old one were bugs again. > > To show the quantitative side of my argument: > > The default change to parallel building in dh compat 10 alone has caused > a three digit number of RC bugs, popping up at a pace of 1-2 RC bugs > per week for several years. > > The problem is that anything that works for only 99% of all packages > results in such a high number of new bugs. > > Parallel build bugs slipping through an upload can happen, > but maintainers not going through the upgrading checklist > and running debdiff between old and new packages as well > as testing them when doing dh compat bumps is harder to > excuse - and in practice this does happen. 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. -- WBR, wRAR signature.asc Description: PGP signature
Re: Do we want to Require or Recommend DH
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. 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. 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? Kind regards Andreas. -- http://fam-tille.de
Re: Do we want to Require or Recommend DH
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. forbid binary uploads for everyone. allow binary uploads for some people for some packages sometimes. -- 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 Description: PGP signature
Re: Do we want to Require or Recommend DH
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 uploading .debs built in a broken env. > > Not sure if we can fix this and how. > > forbid binary uploads for everyone. allow binary uploads for some people > for some packages sometimes. People will find a way. Adrian was talking about uploading broken source packages, I just provided a different example of the same problem. -- WBR, wRAR signature.asc Description: PGP signature
Re: Do we want to Require or Recommend DH
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 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. Its the first time that I hear criticism about d-shlibs usage and I'm fine with discussing this but I'd prefer not to spoil the current thread. > 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. I for myself prefer to debug code based on the same tool set. > >... > > 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 I agree that these are potential sources of bugs. However, I do not see much evidence that if an NMUer / team member does any edit on some d/rules file would be different to the cases above. > 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. +1 (But I do not see any argument against using dh here) > 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. NMUers should do debdiff - no matter what change was done. And yes, it happened also to me in the past once or twice that I uploaded an empty package or package missing some files. I do not remember whether it was connected to a change to dh or not ... but mistakes happen. The fact that we might end up with broken NMUs is IMHO orthogonal to any cdbs to dh change. > 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. As far as I understood the point of the discussion is that we want to get the whole archive more uniform to reduce the potential causes for bugs *in* *the* *future*. This might come at the expense of some bugs when doing so and IMHO the beginning of a release cycle (= after Buster release) is a sensible point in time to do so. BTW, Adrian, thanks for all your patience and bug fixing at an extremely high rate. It is really welcome and appreciated and I think its a good chance to mention this explicitly here. Kind regards Andreas. -- http://fam-tille.de
Re: Do we want to Require or Recommend DH
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 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. > > 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? linux is one. I did a lot of work to address lintian warnings last year, and most of that did not involve debian/rules*. Ben. -- Ben Hutchings I haven't lost my mind; it's backed up on tape somewhere. signature.asc Description: This is a digitally signed message part
Re: Do we want to Require or Recommend DH
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. > > > > > > >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. > > Its the first time that I hear criticism about d-shlibs usage It is fine in the current "maintainer can do anything" world. > and I'm > fine with discussing this but I'd prefer not to spoil the current > thread. >... It is actually part of it, due to: >... > As far as I understood the point of the discussion is that we want to > get the whole archive more uniform to reduce the potential causes for > bugs *in* *the* *future*. >... If this is the point, then weird tools on top of dh are part of the problem just as weird buildsystems are. >... > > 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. > > I for myself prefer to debug code based on the same tool set. >... This is pretty much impossible. dh is nice when it supports whatever you want to do, but for everything else it is just another layer you have to understand when debugging and fixing problems. Imagine you want to make ghc pass an additional flag to gcc. The layering is as follows: Debian haskell scripts upstream build system ghc gcc You end up at questions: How can I tell ghc to pass a parameter to gcc? How can I tell the upstream build system to pass a parameter to ghc? How can I tell the Debian haskell scripts to pass a parameter to the upstream build system? debian/rules is already a 3-line #!/usr/bin/make -f include /usr/share/cdbs/1/rules/debhelper.mk include /usr/share/cdbs/1/class/hlibrary.mk It wouldn't help you if that would be changed to a 3-line #!/usr/bin/make -f %: dh $@ --with haskell In either case there is a huge Haskell-specific build machinery you have to understand for making some kinds of debugging or changes. > Kind regards > > Andreas. 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
Re: Do we want to Require or Recommend DH
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. > > > > Based on what enters the archive, "debdiff between old and new package" > > already seems to be something that many people are not doing - then > > cleaning up after mass-NMUs would be much work. > > > > I have even seen maintainers blindly replacing a complex old > > debian/rules with the dh 3-liner, and all the bugfixes and > > workarounds in the old one were bugs again. > > > > To show the quantitative side of my argument: > > > > The default change to parallel building in dh compat 10 alone has caused > > a three digit number of RC bugs, popping up at a pace of 1-2 RC bugs > > per week for several years. > > > > The problem is that anything that works for only 99% of all packages > > results in such a high number of new bugs. > > > > Parallel build bugs slipping through an upload can happen, > > but maintainers not going through the upgrading checklist > > and running debdiff between old and new packages as well > > as testing them when doing dh compat bumps is harder to > > excuse - and in practice this does happen. > > > > There is no perfect solution here > > What makes reproducible-builds not the perfect fit for this? > > Whenever I converted a package to dh or bumped debhelper compat level, I > always > checked whether the produced binaries were bit-by-bit identical to the ones > before. Don't assume everyone follows the same high standards as you do. > Are there many errors that I would be missing by relying on reproducibility > results? The parallel build issues I mentioned might be missed, but this is more exceptional. dh compat 12 defaulting to dh_dwz might make the -dbgsym packages different, and other intentional differences might exist. > Thanks! > > cheers, josch 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
Re: Do we want to Require or Recommend DH
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 this d/rules file? > > linux is one. > > I did a lot of work to address lintian warnings last year, and most of > that did not involve debian/rules*. Please call me over-picky but without checking the history is your "most" not a sign that there is at least one change to d/rules which was needed to fix some lintian issue. I do not want you to change linux d/rules file and I think it is pretty safe from beeing NMUed just to switch to dh. My point was that I doubt that any "working for years" d/rules has no lintian issues. Kind regards Andreas. -- http://fam-tille.de
Re: Do we want to Require or Recommend DH
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 of new
> packages, while creating no expectation that these requirements be met
> of older packages.
>
> In general, if a policy requirement or convention should apply to new
> packages, then it should apply to existing packages, too. But
> specifically where applying the requirement to an existing package is
> hugely more work than applying it to a new package, perhaps the
> requirement ought to be limited to new packages alone.
There is a big distinction between recommendations which directly
affect the functioning of the binary packages, and recommendations
which make future development easier.
For the latter - and use of dh is an example - it makes a lot of sense
to make the recomendations stronger for new packages.
I also think it would be very valuable for policy to recommend things
like this as the usual case, without mandating them. If for any
reason the maintainer doesn't want to use dh, then they can leave a
wontfix bug open (or something) to document the reasons.
My own anecodote:
Last year I converted src:xen to dh from the previous baroque system
(which I think was based on a clone-and-hack of the machinery in
src:linux.) The result is massively better.
But it was serious work to repeatedly debdiff the results, review each
individual weird thing and decide whether to keep it, try to reproduce
its effects with a dh override or whatever, etc. This needed a high
level of familiarity with both the underlying software and Debian's
packaging practices. Even so I caused a handful of regressions.
One thing that I found really good about dh is that you only have to
write code about things that are unusual. This provides an excellent
opportunity to leave a comment next to each weird thing explaining why
it's there.
https://browse.dgit.debian.org/xen.git/tree/debian/rules#n111
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Re: Do we want to Require or Recommend DH
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 there. > https://browse.dgit.debian.org/xen.git/tree/debian/rules#n111 wow, that's a *really* nicely documented rules file, kudos! -- tschau, Holger --- holger@(debian|reproducible-builds|layer-acht).org PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C signature.asc Description: PGP signature
Re: Do we want to Require or Recommend DH
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't have to touch for years, but I checked and I actually converted them to dh that many years ago... Regards, Thibaut. signature.asc Description: OpenPGP digital signature
Re: Do we want to Require or Recommend DH
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 result a package with no lintian > > > warnings without changing this d/rules file? > > > > linux is one. > > > > I did a lot of work to address lintian warnings last year, and most of > > that did not involve debian/rules*. > > Please call me over-picky but without checking the history is your > "most" not a sign that there is at least one change to d/rules which was > needed to fix some lintian issue. I can only see one change that dh would have handled for us. > I do not want you to change linux > d/rules file and I think it is pretty safe from beeing NMUed just to > switch to dh. Indeed. There is definitely scope for simplification, but it takes a lot of knowledge and time to do that. Given what others have said, I doubt that dh in its current state could handle the multiple configurations, which is a shame. > My point was that I doubt that any "working for years" > d/rules has no lintian issues. If "working for years" also implies unchanged for years, yes I agree. Ben. -- Ben Hutchings I haven't lost my mind; it's backed up on tape somewhere. signature.asc Description: This is a digitally signed message part
Re: Do we want to Require or Recommend DH
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.
> > https://browse.dgit.debian.org/xen.git/tree/debian/rules#n111
>
> wow, that's a *really* nicely documented rules file, kudos!
Thanks for the compliment. This is there for my benefit as much as
anyone else's. Having done all the digging to figure all these things
out, I definitely want so save my future self from doing it all again!
Also documenting things means both that everyone else is much less
likely to delete it or break it, and that if it goes wrong or becomes
obsolete, we will be able to fix it or drop it as applicable.
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 dh and cdbs make this easier.
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Re: Do we want to Require or Recommend DH
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 dh and cdbs make this easier. That's another nice summary (and admittedly also true for cdbs). Kind regards Andreas. -- http://fam-tille.de
Re: Do we want to Require or Recommend DH
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 fewer problems than people trying to > > > change that just for the sake of it. > > In my experience ancient debian/rules runes are also a cause for > > repeated RC bugs and the need for NMUs. > > Real life example: > > https://tracker.debian.org/media/packages/libm/libmp3-info-perl/changelog-1.24-1.2 > 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. I hope I test them well enough :) (And thanks for the kind feedback.) > There is no perfect solution here and I also get your point, > what should be taken into consideration is that there is a > tradeoff between the benefits and the regressions of breaking > changes like dh compat bumps or even conversions to dh. Agreed; additional changes are additional chances for mistakes. Still, I wanted to make the points that - further adoption of dh(1) would make my life easier by creating fewer bugs of certain categories, and - the possibility to switch a package to dh(1) (in cases where I know what that means, as in the example above with a typical perl module; not in complex cases like Marco's examples, and not just for the sake of it) would make bug fixing in NMUs easier for me and even prevent future bugs. Cheers, gregor -- .''`. https://info.comodo.priv.at -- Debian Developer https://www.debian.org : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06 `. `' Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe `- NP: Rigmor Gustafsson: The Moon Is A Harsh Mistress signature.asc Description: Digital Signature
Re: Do we want to Require or Recommend DH
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't matter if its dh, cdbs or old dh_* stuff. > dh will hide everything. It isn't simpler, it *LOOKS* > simpler, but it's a way more complex. No idea where you think that dh hides something - make and dh both print what they are doing. -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F
Re: Do we want to Require or Recommend DH
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. the changes which were necessary to inject the hardening build flags; I submitted a few hundred to the BTS when we got started with it, which was very simple for anything using dh (where is was enabled by default when using compat level 9) and needed more effort for anything based on traditional debhelper and or even not using debhelper at all. Cheers, Moritz
Re: Do we want to Require or Recommend DH
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 that one to something else? The package, > basically, consists of a shell script and a man page only. I would personally *especially* use dh for packages this simple. 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. At some point in the past someone, probably you, has had to think about: - which dh_foo helpers need to be included in the list and which can be excluded - which order they go in which has probably been done correctly, but maybe not - I can't tell. The fact that they might have been done incorrectly isn't so bad: if they're wrong it's just a bug, and we can fix bugs. The fact that it would take thought to work out whether they're correct is more problematic. At some point in the past someone, probably you, has had to make this package Policy-compliant when the -arch and -indep targets became mandatory in order to make Build-Depends-Indep practically useful (perhaps this package is new enough that you did that as part of its initial packaging, but either way, someone had to think about it). Adding the -arch and -indep targets went as slowly as it did because many packages needed (trivial) per-package changes to enact it. Part of the value of a dh rules file is that (as Ian Jackson said elsewhere in this thread) the boilerplate part is trivial, and each non-boilerplate part (override target) indicates something that is unusual about this package. A minimal dh rules file immediately tells a reader "this is a completely ordinary build process" and that's a valuable thing to convey to a reader. smcv
Re: Do we want to Require or Recommend DH
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 twice (with and without dh), inspects the resulting changes to the binary packages with diffoscope and is confident that each change is appropriate. Here you state your opinion but you haven't provided any rationale for it. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland ⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net ⠈⠳⣄ Please do not CC me, I am subscribed to the list.
Re: Do we want to Require or Recommend DH
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 one of the simplest possible packages (in non-free), doom-wad-shareware, that is even simpler: it consists of three files total: /usr/share/doc/doom-wad-shareware/changelog.Debian.gz /usr/share/doc/doom-wad-shareware/copyright /usr/share/games/doom/doom1.wad For the source package, I thought "why do I need debhelper for such a simple package". And so I did things by hand instead¹, and I still screwed something up². This is clearly a stupid case of premature optimisation, yak shaving, etc.; I suspect many other instances of "why bother for such a simple package" in the archive have elements of these too. (An unrelated, but amusing mess-up in this trivial package: for the first 11 years, there was a version mismatch between what was actually in the .deb and what the version claimed) 1. https://sources.debian.org/src/doom-wad-shareware/1.9.fixed-2/debian/rules/ 2. https://tracker.debian.org/news/449441/accepted-doom-wad-shareware-19fixed-2-source-all/ -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland ⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net ⠈⠳⣄ Please do not CC me, I am subscribed to the list.
Re: Do we want to Require or Recommend DH
]] 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 warnings on the source package (primarily because it's not been uploaded for more than ten years) of which only two out of six warnings would be handled automatically by dh. (Yes, also not an important package in the grand scheme of things, and I'm not disagreeing that using dh is a good thing overall. I should probably upload it just to get some of the dust off it.) -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Re: Do we want to Require or Recommend DH
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 be
>> extended: perhaps there are other things that we could require of new
>> packages, while creating no expectation that these requirements be met
>> of older packages.
>>
>> In general, if a policy requirement or convention should apply to new
>> packages, then it should apply to existing packages, too. But
>> specifically where applying the requirement to an existing package is
>> hugely more work than applying it to a new package, perhaps the
>> requirement ought to be limited to new packages alone.
>
> There is a big distinction between recommendations which directly
> affect the functioning of the binary packages, and recommendations
> which make future development easier.
Good point.
> For the latter - and use of dh is an example - it makes a lot of sense
> to make the recomendations stronger for new packages.
>
> I also think it would be very valuable for policy to recommend things
> like this as the usual case, without mandating them. If for any
> reason the maintainer doesn't want to use dh, then they can leave a
> wontfix bug open (or something) to document the reasons.
It might be useful to note here that patches to debian-policy which
suggest using particular tools, without using "recommends", "should" or
"must" (etc.), do not need to go through the Policy Changes Process, and
can just be applied immediately.
For example, in Policy we currently have:
The easiest way to call "dpkg-shlibdeps" correctly is to use a
package helper framework such as debhelper. If you are using
debhelper, the "dh_shlibdeps" program will do this work for you.
and
Note that under some circumstances it may be useful to install a
shared library unstripped, for example when building a separate
package to support debugging. The debhelper *dh_strip`* tool can
create such packages automatically.
This sort of text, which is informative rather than normative, does not
need to go through the consensus-building process.
--
Sean Whitton
signature.asc
Description: PGP signature
Re: Do we want to Require or Recommend DH
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? > > If you're talking about the binary package, fortunes-bofh-excuses. It > has some lintian warnings on the source package (primarily because it's > not been uploaded for more than ten years) of which only two out of six > warnings would be handled automatically by dh. >From a developer point of view I'm talking about *any* lintian warnings so for sure also about source package warnings. > (Yes, also not an important package in the grand scheme of things, and > I'm not disagreeing that using dh is a good thing overall. I should > probably upload it just to get some of the dust off it.) :-) Kind regards Andreas. -- http://fam-tille.de
Re: Do we want to Require or Recommend DH
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 consensus correctly. Then we'll go from there. It's going to take me a few days to write up such a consensus call. I'm working on other things too, and reading a mailing list discussion like this to judge consensus requires care. --Sam
Re: Do we want to Require or Recommend DH
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 published a blog post relevant to the discussion we're having: I added `dh` to debhelper a decade ago, and now Debian is considering making use of `dh` mandatory. Not being part of Debian anymore, I'm in the position of needing to point out something important about it anyway. So this post is less about pointing in a specific direction as giving a different angle to think about things. http://joeyh.name/blog/entry/80_percent/ -- Sean Whitton signature.asc Description: PGP signature
Re: Do we want to Require or Recommend DH
> "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 those who haven't seen it, the original author of dh, Joey Sean> Hess, has just published a blog post relevant to the Sean> discussion we're having: I've read the blog post. I think Joey's points are very consistent with our discussion here. I hope it's not too much of a spoiler for my upcoming summary, but my view is that we identified several areas in the discussion where dh is not the right solution. We'll probably identify more over time. There will be good reasons for not using dh in a particular situation. --Sam
Re: Do we want to Require or Recommend DH
❦ 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> Hess, has just published a blog post relevant to the > Sean> discussion we're having: > > I've read the blog post. > > I think Joey's points are very consistent with our discussion here. 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 control flow constructs. - The Elements of Programming Style (Kernighan & Plauger) signature.asc Description: PGP signature
Re: Do we want to Require or Recommend DH
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, the original author of dh, Joey > > Sean> Hess, has just published a blog post relevant to the > > Sean> discussion we're having: > > > > I've read the blog post. > > > > I think Joey's points are very consistent with our discussion here. > > 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. I guess the answer to your question is "no" but please beware that this thread is about what is _convenient_ (for the package maintainer and/or for the majority of Debian), not what is _possible_, - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Do we want to Require or Recommend DH
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. > > > > Sean> For those who haven't seen it, the original author of dh, Joey > > Sean> Hess, has just published a blog post relevant to the > > Sean> discussion we're having: > > > > I've read the blog post. > > > > I think Joey's points are very consistent with our discussion here. > > 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. This would be less uniform that it sounds. Technically a package that overrides *all* dh targets with something completely different is using dh. And the result of someone spending several man months on converting the Debian Haskell scripts to dh might be relatively close to that. As an example, look at https://tracker.debian.org/media/packages/h/haskell-sandi/rules-0.4.2-2 You can see by the path that /usr/share/cdbs/1/class/hlibrary.mk uses CDBS, but if it would use dh instead this wouldn't make a huge difference here. As developer you are not usually working directly with low-level CDBS or dh functionality, what you are using is the higher level haskell-devscripts functionality built on top of that. If you ever have to use low-level CDBS or dh functionality directly, then things can get really messy since you might break what haskell-devscripts is doing. DEB_ENABLE_TESTS is an API provided by haskell-devscripts. 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
Re: Do we want to Require or Recommend DH
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 control flow constructs. > - The Elements of Programming Style (Kernighan & Plauger) > 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 potential. Maybe I'm just not seeing it? Note that I orphaned the package quite some time ago, so feel welcome to simplify it as much as possible on Salsa. Best -rt >
Re: Do we want to Require or Recommend DH
> "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 potential. Maybe I'm just not Reinhard> seeing it? This has been said earlier in the discussion, but to summarize. Even if you don't simplify the package, uniformity has significant value. First, it makes it easier for others to analyze correctness. Second, it makes it easier to adopt future changes. I'm not asking you to go mess with a package you orphaned, simply summarizing an answer that it sounds like you missed. --Sam
Re: Do we want to Require or Recommend DH
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
> potential. Maybe I'm just not seeing it?
I think the dh-based rules file would be about 2/3 the length. I look
particularly at the binary-arch target and I think "why are we listing
all of this explicitly, and specifying an order". And what is that
DEB_HOST_GNU_TYPE for ? Seems like hand-coded cross-compilation
support. I bet dh would Just DTRT. etc.
> Note that I orphaned the package quite some time ago, so feel welcome to
> simplify it as much as possible on Salsa.
Heh. Well, like Sam, I am responding because I failed my saving throw
against XKCD-386 [1], not to try to badger you into doing work on a
package you don't much care about any more. I don't feel converting
this package, even as an example to others, is a thing that I want to
spend my time on...
Regards,
Ian.
[1] https://xkcd.com/386/
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Re: Do we want to Require or Recommend DH
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 need to evaluate all of these. These are more or less just as complicated with dh, but the entire point is that I only need to remember one complicated thing rather than lots. * The package uses findstring rather than filter when searching DEB_BUILD_OPTIONS. I know that filter is preferred I think because findstring will do substring matches. I need to remember why that's bad for DEB_BUILD_OPTIONS and consider whether it's a bug. * What's with the debug DEB_BUILD_OPTION. I'd need to make sure that by default -g is included per policy. * It doesn't look like noopt is explicitly handled. Does dpkg-info.mk do that for me? I can't remember; better go look. It's probably going to be a combination of dpkg-buildflags, the makefile fragment, configure's handling of environment variables, etc. Yeah, it's just as complicated with dh, but I have high confidence dh gets this right. * It looks like the version and configure handling are a little prickly in this package; I get the impression that the configure script may not be entirely well behaved. Or perhaps it's just maintainer style. With dh that would stand out one way or the other and be obvious. *There's an init script and a systemd unit. That'll break when this goes to compat 11 or 12. (Well really that situation's going to be broken with compat 11 anyway), but getting the advantages of the systemd handling in compat 12 would be better with dh. * As Simon pointed out I'd need to go check the ordering of all the debhelper calls. I'm fairly sure this is correct, but it would be nice to not need to worry about that. So, yes, this package would be much more appealing to third parties who need to look at it after the dh conversion. I fully acknowledge that conversion is real work. Each of the bullet points I enumerate above and several others would need to get checked. We've talked about how when doing such conversions we should check and make sure we get identical binaries out. Here I'm not sure that's right. I'm not sure the existing buildflag, debug, optimization and stripping behavior is right. So, the conversion might be harder to the extent I'm needing to check correctness of the existing packaging. Am I jumping up and down to go do that work on this package? Absolutely not. do I hope whoever adopts it does that work? Yes.
Re: Do we want to Require or Recommend DH
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 uniformize our packaging practices towards dh. > > -- > > Use the fundamental control flow constructs. > > - The Elements of Programming Style (Kernighan & Plauger) > 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 potential. Maybe I'm just not > seeing it? > Note that I orphaned the package quite some time ago, so feel welcome to > simplify it as much as possible on Salsa. Well, I took a stab at this, but wasted far more time dealing with crlf nonsense on the vcxproj.user files in the git tree than on the actual conversion to dh(1). So here's a patch which shows that even in its most direct form, converting this package to dh results in a shorter debian/rules which trims a fair amount of boilerplate. Further improvements are definitely possible. Simplifying debian/rules to only need to declare the exceptions, and not the boilerplate, is always a win. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org commit a5e8d7c7c2b16ade5197c497491cb73e82784c19 Author: Steve Langasek Date: Tue May 21 10:38:49 2019 -0700 Convert to dh(1). diff --git a/debian/changelog b/debian/changelog index 4ff829f4..97e4dca9 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,9 @@ +boxbackup (0.13~~git20180819.g2f5b556-2) UNRELEASED; urgency=medium + + * Convert to dh(1). + + -- Steve Langasek Tue, 21 May 2019 10:38:32 -0700 + boxbackup (0.13~~git20180819.g2f5b556-1) unstable; urgency=medium * New upstream pre-release diff --git a/debian/clean.sh b/debian/clean.sh index 90a30513..1482640c 100644 --- a/debian/clean.sh +++ b/debian/clean.sh @@ -1,8 +1,6 @@ #!/bin/sh -rm -rf debug/ rm -rf local/ rm -rf parcels/ -rm -rf release/ rm -rf docs/htmlguide/ rm -rf docs/man/ diff --git a/debian/rules b/debian/rules index b67b9519..a44d062e 100755 --- a/debian/rules +++ b/debian/rules @@ -5,73 +5,56 @@ include /usr/share/dpkg/pkg-info.mk -# These are used for cross-compiling and for saving the configure script -# from having to guess our platform (since we know it already) -DEB_HOST_GNU_TYPE ?= $(shell dpkg-architecture -qDEB_HOST_GNU_TYPE) -DEB_BUILD_GNU_TYPE ?= $(shell dpkg-architecture -qDEB_BUILD_GNU_TYPE) - TMP:=$(CURDIR)/debian/tmp -ifneq (,$(findstring debug,$(DEB_BUILD_OPTIONS))) - CFLAGS += -g -endif -ifeq (,$(findstring nostrip,$(DEB_BUILD_OPTIONS))) - INSTALL_PROGRAM += -s -endif +%: + dh $@ -configure: configure-stamp -configure-stamp: - dh_testdir +override_dh_autoreconf: echo "$(DEB_VERSION_UPSTREAM_REVISION)" > VERSION.txt echo "boxbackup" >> VERSION.txt - sh -x ./bootstrap - ./configure $(DEB_EXTRA_CONFIG_FLAGS) LDFLAGS="-Wl,--as-needed" - touch configure-stamp + dh_autoreconf sh -- -x ./bootstrap + +configure: override_dh_autoreconf + : + +override_dh_auto_configure: configure + dh_auto_configure -- LDFLAGS="-Wl,--as-needed" -build-stamp: configure-stamp - dh_testdir - $(MAKE) V=1 +override_dh_auto_build: + dh_auto_build -- V=1 + +override_dh_auto_test: # the testsuite is only really maintained on i386 and amd64 ifneq (,$(filter $(DEB_HOST_ARCH),i386 amd64)) ifeq (,$(findstring nocheck,$(DEB_BUILD_OPTIONS))) ./runtest.pl ALL endif endif - touch build-stamp docs/docbook/instguide.pdf: $(MAKE) -C docs instguide cd docs/docbook && docbook2pdf instguide.xml -docs/docbook/adminguide.pdf: configure-stamp +docs/docbook/adminguide.pdf: override_dh_auto_configure $(MAKE) -C docs adminguide cd docs/docbook && docbook2pdf adminguide.xml docs: docs/docbook/instguide.pdf docs/docbook/adminguide.pdf $(MAKE) -C docs manpages -build-arch: build-stamp -build-indep: docs - -build: build-arch build-indep +build-arch: docs -clean: - dh_testdir - dh_testroot - dh_clean build-stamp configure-stamp +override_dh_auto_clean: echo "USE_SVN_VERSION" > VERSION.txt echo "boxbackup" >> VERSION.txt - [ ! -f Makefile ] || make clean - sh debian/clean.sh - dh_clean config.log config.status + dh_auto_clean -install: DH_OPTIONS= -install: build - dh_testdir - dh_testroot - dh_prep - dh_installdirs +override_dh_clean: + sh debian/clean.sh + dh_clean +override_dh_install: mkdir -p $(TMP)/etc/logcheck/ignore.d.workstation mkdir -p $(TMP)/etc/logcheck/ignore.d.server install -m 644 debian/boxbackup-server.logcheck.ignore $(TMP)/etc/logcheck/ignore.d.workstation/boxbacku
Re: Do we want to Require or Recommend DH
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 personally perhaps when it requires no overrides or very very few of them, or as a replacement for equivs. I do not have any major problem with debhelper nor dh, I find *both* styles more pleasant than a hand-crafted debian/rules, but from here it seems like some in this thread are oblivious to problems with its usage. Design -- * debhelper design's principle has been to be a thin layer, most of the heavy lifting used to get delegated to other tools and/or lower-layers. * Both cdbs and dh are based on similar principles, which is to cover as much as possible automatically, and override/diverge on the specifics. The problem I see though is that they are implemented inside-out, and that is one big reason both end up being so much more complex than they need to be. This is obviously not a problem of their making! * Both debhelper and cdbs have a concept of a versioned API. Which is nice because it makes it possible to introduce staged changes that could otherwise break the world. debhelper seems to be more strict about adhering to its API though, and it 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. This made me realize the same applies to dpkg's make fragments (which tend to be used with dh too), so I'll be adding man pages for those during 1.20.x. :) * dh uses an implementation hack to be able to introspect on make. This is something that has always slightly put me off. I'm counting the days until I can remove a similar but way less clever hack in dpkg-buildpackage that tries to introspect on the build targets! Technical - * Not so simple: The proclaimed simplicity is only apparently so. Using dh might result in shorter debian/rules files, it might (perhaps) result in debian/rules listing only the exceptions; all these are one side of simplicity. At the same time it makes things more complex because it's yet another layer, an abstraction which hides (at the source level) implementation details, which you still need to know when having to modify the packaging; you need to know how each of dh, debhelper, the various tools debhelper uses, make, shell, the upstream build system, the source format and patching, the dpkg toolchains, etc. all work, and how they interact. * Complex is still complex: For simple cases, it can indeed be very simple and obvious, for complex cases with tons of overrides and make variables, many times it does not seem better than an unrolled debhelper debian/rules file. * Not so uniform: Uniformity even with required usage of dh (is not and) would not be as uniform as people might want to believe. This is still dependent on other helpers used (and which, say dh-exec), on make/shell style, on whether you implement the logic in make or shell or an external package-specific program (in whatever language) that you call from debian/rules, etc. * No free global change: Makes pushing global changes somewhat easier? Yes, but also taking into account that any such change in most cases will still require a compat level bump, the maintainers making sure it works, and that any override has the potential to disable those changes. The main advantage is that it might remove the load on maintainers having to recall to do that specific change, they just need to make sure it works. It might also play in the other direction, with maintainers missing that they need to check for these changes "because dh takes care of everything". But this just enables a "passive deferred transition", and people that want to see a transition done *now* still might need to do tons of work. Social -- * It has already naturally gained majority mindshare, because in most cases and for most people, it's obviously better than the alternatives, I expect this will keep going as debhelper/dh improves, why the need for a forced push then for the people who are not yet convinced? This always looks suspect to me. For cases like this, I always find it's better to convince people with good arguments or better implementation and/or documentation, not with force, but dunno. * A hard requirement means innovation might be thwarted, even if innovation is excempt, it would require people to justify beforehand (either publicly or to themselves) whether the new solution is going to end up being really better than the status quo even before it's started. * Optimizing for NMUs seems wrong, we should be optimizing for long term maintainership. Something that can only b
Re: Do we want to Require or Recommend DH
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 technical¹ reason for disliking cdbs besides its lack of documentation is its exposing the make language where dh hides it. > This made me realize the same applies to dpkg's make fragments > (which tend to be used with dh too), so I'll be adding man pages for > those during 1.20.x. :) Nice to know that my total² lack of documenting cdbs has at least been helpful in improving _other_ documentation ;-) - Jonas ¹ A common _non-technical_ reason is that cdbs is less popular than dh and therefore a reason Debian has less contributors than if they were given less choice. ² All existing documentation predates my taking lead of cdbs in 2009. -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Do we want to Require or Recommend DH
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 be, a 100% solution. I’d also throw in that monocultures are not good, and that people in general are happier when they aren’t forced into anything. Just yesterday I had a bug that wouldn’t have happened with a non-dh7 rules file (incidentally, ordering matters, so I had to add a call to mkdir -p debian/binarypackagename/some/directory into an over‐ ride). And finally, rules with too many overrides are actually worse readable than classic debhelper style. I also have packages where the automatic build system detection of dh is wrong. Understandably wrong, but wrong nevertheless. Oh, and… to learn, automagisms are not so good, because you don’t see what’s going on, and can’t change it on an intuitive or more fine-granular level (though with DH_VERBOSE=1 mandated by default by recent Policy changes, this may have improved a little). So… to each their own. I’d make a case for non-debhelper to be allowed, but I know that’s not majority-capable… but if people wish to use debhelper, dh7, or even *shudder* dbs or cdbs, fine. Remember people make this often in their spare time and aren’t getting paid for it so please keep the fun factor. Thanks, //mirabilos -- This space for rent. https://paypal.me/mirabilos to support my work.
Re: Do we want to Require or Recommend DH
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 yesterday I had a bug that wouldn’t have happened with a non-dh7 > rules file (incidentally, ordering matters, so I had to add a call to > mkdir -p debian/binarypackagename/some/directory into an over‐ ride). dh_installdirs runs pretty early in the install target, what needed that directory before dh_installdirs? > I also have packages where the automatic build system detection > of dh is wrong. Understandably wrong, but wrong nevertheless. It's a feature of dh_auto_* and not of dh. > Oh, and… to learn, automagisms are not so good, because you don’t > see what’s going on, You see what helpers are executed. You don't always see what do they do but that's unrelated to dh(1). > (though with DH_VERBOSE=1 mandated by default by recent Policy changes, > this may have improved a little). If you mean "The package build should be as verbose as reasonably possible" then it doesn't really mandate DH_VERBOSE=1. -- WBR, wRAR signature.asc Description: PGP signature
Re: Do we want to Require or Recommend DH
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 they don't need to learn > all ways to do something. Who says people need to learn _all_ ways? Must we all learn the ways of Java and DKMS and Haskell and and...? Nice if we can _generally_ handle _most_ packages. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Do we want to Require or Recommend DH
> "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 doesn't actually make that argument. >Not being part of Debian anymore, I'm in the position of needing to >point out something important about it anyway. So this post is less >about pointing in a specific direction as giving a different angle to >think about things. He argues that dh may have evolved to be around a 96% solution at this point. That's entirely consistent with the idea that not using dh could be a bug absent an exceptional situation. (Appologies for not looking up the wording from Ian's message; I mean what Ian calls unusual here.) Thorsten> tl;dr: dh started as 80% solution, it’s maybe an 96% Thorsten> solution now, but it’s not intended as, and won’t be, a Thorsten> 100% solution. Nor have we claimed that it is. There are several reasons for not using dh we've already identified. Thorsten> I’d also throw in that monocultures are not good, and that Thorsten> people in general are happier when they aren’t forced into Thorsten> anything. Agreed. Working on new tooling clearly needs to be one of the reasons for not using dh to allow for development of new things. Thorsten> Just yesterday I had a bug that wouldn’t have Thorsten> happened with a non-dh7 rules file (incidentally, ordering Thorsten> matters, so I had to add a call to mkdir -p Thorsten> debian/binarypackagename/some/directory into an over‐ Thorsten> ride). And finally, rules with too many overrides are Thorsten> actually worse readable than classic debhelper style. Thorsten> I also have packages where the automatic build system Thorsten> detection of dh is wrong. Understandably wrong, but wrong Thorsten> nevertheless. Thorsten> Oh, and… to learn, automagisms are not so good, because Thorsten> you don’t see what’s going on, and can’t change it on an Thorsten> intuitive or more fine-granular level (though with Thorsten> DH_VERBOSE=1 mandated by default by recent Policy changes, Thorsten> this may have improved a little). Thorsten> So… to each their own. I’d make a case for non-debhelper Thorsten> to be allowed, but I know that’s not majority-capable… but Thorsten> if people wish to use debhelper, dh7, or even *shudder* Thorsten> dbs or cdbs, fine. Remember people make this often in Thorsten> their spare time and aren’t getting paid for it so please Thorsten> keep the fun factor. The fun factor is important. My reading of the community consensus is that the points you bring up have been consider by the community. You did not bring up new issues. my reading is that the community believes that the fun factor of more uniformity when dealing with a lot of packages justifies the restriction of maintainer preference when there's not a sufficient justification for a tool other than dh. You're absolutely right that there is a tradeoff here. And I think that Debian of 10 or 15 years ago would have evaluated the tradeoff between the needs of a single maintainer and the needs of people doing work across a lot of packages differently. --Sam
Re: Do we want to Require or Recommend DH
> "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 forced into >> anything. Yet people in general are also happier when they don't >> need to learn all ways to do something. Jonas> Who says people need to learn _all_ ways? Jonas> Must we all learn the ways of Java and DKMS and Haskell and Jonas> and...? no, but some of us must or at least must be prepared to.
Re: Do we want to Require or Recommend DH
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 something. > > Who says people need to learn _all_ ways? > > Must we all learn the ways of Java and DKMS and Haskell and and...? > > Nice if we can _generally_ handle _most_ packages. To be able to handle most packages we must mandate that most packages use an uniform workflow. That's different from "monocultures are not good" etc. -- WBR, wRAR signature.asc Description: PGP signature
Re: Do we want to Require or Recommend DH
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 community consensus is that the points you bring up >have been consider by the community. >You did not bring up new issues. This is diametral opposite to: >my reading is that the community believes that the fun factor of more >uniformity when dealing with a lot of packages justifies the restriction >of maintainer preference when there's not a sufficient justification for >a tool other than 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.) Yes, some must learn those ways, but I don’t mind; that doesn’t mean I’m more comfortable in dh7. Usually I’m not except for extremely simple packages, or, partially, really new packages. >You're absolutely right that there is a tradeoff here. >And I think that Debian of 10 or 15 years ago would have evaluated the >tradeoff between the needs of a single maintainer and the needs of >people doing work across a lot of packages differently. Is “the Debian of today” the *Debian* of today, or just a couple of very involved people? Do you consider all those people who just take care of their own package, or couple of packages, in what little spare time they have? I doubt those very involved people, with hundreds of packages in their DDPO already (don’t laugh, I saw that), could shoulder the burden, were those others to leave disgruntled by things being forced onto them. bye, //mirabilos -- „Cool, /usr/share/doc/mksh/examples/uhr.gz ist ja ein Grund, mksh auf jedem System zu installieren.“ -- XTaran auf der OpenRheinRuhr, ganz begeistert (EN: “[…]uhr.gz is a reason to install mksh on every system.”)
Re: Do we want to Require or Recommend DH
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.)
"Maintainer" is precisely the hat we wear when working on our own
packages. But working with Debian is much more than just working on
our own packages.
There is QA work on the many packages with no specific maintainer;
there are cross-archive campaigns such as reproducible builds,
architecture support, init system diversity, i18n/l10n, and so on.
There is RC bugfixing etc. to try to make a release. There is
security support, stable release management, and backports.
And of course as users and downstreams we wish to exercise our
software freedom: ie to modify the programs that run on our computer.
That freedom being the point of Debian.
For all these tasks, we often need to interact with or modify the
package's build machinery (to varying extent). That means learning
the build machinery of every package we work on - at least well enough
to accomplish the task at hand.
> Is 'the Debian of today' the *Debian* of today, or just a couple of
> very involved people?
Well, Sam posed a consultation here on debian-devel. My assessment of
the rough consensus of the discussion here is very similar to Sam's.
Do you agree with Sam's assessment of the apparent consensus on this
list ?
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 GR would be a collosal waste of time. This issue is
not important enough. In particular, because the consensus is *not*
that you will *have to* change your packages. What this discussion
has mostly concluded is that we should issue a *recommendation*.
*Not* a mandate.
You may be gently encouraged to change your packages. In practice if
you refuse, it is not likely that anyone will want to fight you over
it. You will probably be able to leave the bug open "wontfix", if
there is a bug at all, indefinitely.
> I doubt those very involved people, with hundreds of packages in their
> DDPO already (don't laugh, I saw that), could shoulder the burden, were
> those others to leave disgruntled by things being forced onto them.
So, nothing will be forced onto you and you do not need to fight this.
But I would like you to consider this: the primary responsibility of
the maintainer of a Debian package is a *management* responsibility.
Our job as maintainer is not to do all the work. If we like to do the
work ourselves, great. If we don't and the work goes undone, well,
c'est la vie; maybe someone else will have the energy.
But our one un-shirkable responsibility is that of creating an
environment where *others* can contribute.
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Re: Do we want to Require or Recommend DH
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 their own packages, except those people who actually prepare that NMU debdiff, yeah. Not sure what did you mean by this. > Yes, some must learn those ways, but I don’t mind; Does this mean "some must learn many different things to be able to make NMUs, but I don’t mind" or am I mistaken? -- WBR, wRAR signature.asc Description: PGP signature
Re: Do we want to Require or Recommend DH
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 by specialists. I didn’t say *nobody* would need to learn the others, just that not *everyone* needs, especially not at first. >There is RC bugfixing etc. to try to make a release. There is This is either a good learning chance, or just tackle an RC bug in another package. >security support, stable release management, and backports. Again, specialists. >Well, Sam posed a consultation here on debian-devel. My assessment of >the rough consensus of the discussion here is very similar to Sam's. My point was to raise concerns of mine. >Do you agree with Sam's assessment of the apparent consensus on this >list ? I’ve not read the entire discussion here. I stumbled upon this by reading the DPL news and thus posted because I feared that the point important to me might be underrepresented. >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 ? Hmm, did not consider it, but a GR could fight being forced to use dh7 if needed. Thanks for the idea. >You may be gently encouraged to change your packages. In practice if >you refuse, it is not likely that anyone will want to fight you over >it. You will probably be able to leave the bug open "wontfix", if Perhaps. Perhaps not. Perhaps, if that’s acceptable, it’ll be enough. >there is a bug at all, indefinitely. If. If it isn’t, leaving it wontfix or closing is guaranteed to be acceptable. If it is, some clarification that it is acceptable is needed or we’re entering vague territories (such as, where people who don’t like a maintainer file RM requests against their packages because they don’t follow this-and-that latest fad). >So, nothing will be forced onto you and you do not need to fight this. If optimistic, yes. >But I would like you to consider this: the primary responsibility of >the maintainer of a Debian package is a *management* responsibility. Oh sure. But I just want to make the world better by packaging some software for Debian, some of which I happen to be upstream of, some of which I happen to have become upstream because of packaging it. I occasionally join in teams, but mostly just wish to quietly do my thing, undisturbed. >But our one un-shirkable responsibility is that of creating an >environment where *others* can contribute. Oh, sorry, but, I disagree. Others can contribute in other packages, I can do mine just fine. (Of course, the occasional contribution is welcome, but I’m not going to bend my ways for it.) Just like when I contribute somewhere, I’m, sometimes extremely rudely, asked to take my problem (or even patch) upstream myself or go sod off. bye, //mirabilos -- exceptions: a truly awful implementation of quite a nice idea. just about the worst way you could do something like that, afaic. it's like anti-design. that too… may I quote you on that? sure, tho i doubt anyone will listen ;)
Re: Do we want to Require or Recommend DH
❦ 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 GR would be a collosal waste of time. This issue is > not important enough. In particular, because the consensus is *not* > that you will *have to* change your packages. What this discussion > has mostly concluded is that we should issue a *recommendation*. > *Not* a mandate. Well, a GR can be quick and it would help to know where people stand instead of having a few vocal people decide for everyone. I think we should impose the use of "dh" for bullseye (with an exception for teams with more then 50 packages), but I honestly don't know how much this opinion is shared. It seems there is a pattern to dissuade people to hold a GR. The last GR I remember is about changing "Chairman" to "Chair" in our constitution. I don't remember it was a waste of time and it was pretty quick. And the last "technical" GR was for systemd in 2014. We are in a project where it is very hard to be heard because you can only participate in endless debates. -- Let him choose out of my files, his projects to accomplish. -- Shakespeare, "Coriolanus" signature.asc Description: PGP signature
Re: Do we want to Require or Recommend DH
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 decide for everyone. I think we should impose the use of "dh" for bullseye (with an exception for teams with more then 50 packages), but I honestly don't know how much this opinion is shared. I followed the discussion closely but i don't get some points. I assume that "dh" is here to stay - so in that case new packages should be done with "dh", older packages should be converted. There might be some packages which are not worth the additional work. Just leave a note why and everyone is happy. So a GR would be a appr. tool to solve this endless discussion fast. last "technical" GR was for systemd in 2014. We are in a project where it is very hard to be heard because you can only participate in endless debates. I for myself have no time for endless debates - i have things to do in Debian and upstream. And it's just boring to read the same arguments pro and esp. contra again and again. I was quiet until now because the debate don't change anything for me firsthand. I use dh for all my packages already and don't think i will change it in the future. The very most packages i'm interested in are dh - so no problem for me to read and maybe fix them if needed. Will i touch complex things written in cdbs? Hell no. Will i touch other complex things not in dh - hell, no, not worth the time. One might think of as a bit stubborn or short sighted, but to be true: It's lack of motivation - learning a bunch of things i'm not interested in to change things i'm not that interested in? Sounds nuts. A solution could be: Deprecate some thing like cdbs an others if they are really deprecated, be verbose about why and don't let packages that using these things go into the repository. Can be done stepwise. My 2¢ Alf
Re: Do we want to Require or Recommend DH
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 disagree. Others can contribute in other packages, > I can do mine just fine. (Of course, the occasional contribution is > welcome, but I’m not going to bend my ways for it.) IMHO this specifies Debian 15 years ago. I fear this attitude will decrease the relevance of Debian in future if we do not have the power to change. Kind regards Andreas. -- http://fam-tille.de
Bootstrapping debhelper (was: Re: Do we want to Require or Recommend DH)
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 > 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. Funnily, we just talked about Architecture:all packages in the bootstrapping context in #debian-bootstrap today with debhelper maintainers. Take away message: A binary package being Architecture:all doesn't remove it from the bootstrap problem because that package also has to be installable i.e: all its transitive Depends must exist as well and those may be Architecture:any, as is also the case for debhelper. So applying this "exception" to the build-depends on debhelper would not be enough. It would also have to be extended to the transitive build dependencies of binaries in the installation sets of those. Unfortunately, if you would indeed traverse the dependency graph in that way you will quickly end up with a strongly connected component of several thousand source packages in it: https://bootstrap.debian.net/history.html Fortunately, this is not really a problem (see below). > I'll be shocked if there's not already a cycle involving building dpkg > requiring a build of debhelper as an example. I can even show you cycles involving dpkg and Haskell, OCaml, Python, Xorg and ruby: https://bootstrap.debian.net/essential.html But all of this is hardly a problem in practice because much of the problem can be worked around by cross-building many of the involved packages before building packages natively. Of course (due to dependency cycles) not all source packages can be cross compiled even if it would technically be possible to do so, given the full archive. So all of this depends on the initial cross-bootstrap phase. Great progress is being made by the rebootstrap project: https://wiki.debian.org/HelmutGrohne/rebootstrap And since recently we also have actual cross-builds of source packages that satisfy their cross-build dependencies: http://crossqa.debian.net/ Long story short: "exception for build-depends on debhelper" as outlined above is not the right way forward to make debhelper bootstrappable. The correct solution is a bit more involved and (due to the prevalence of debhelper) probably involves making debhelper (and its installation set) be part of the cross-bootstrap. But debhelper maintainers are already lurking in #debian-bootstrap so I guess this topic is already covered. :) Thanks! cheers, josch signature.asc Description: signature
dh_testroot usage is still always required (was Re: Do we want to Require or Recommend DH)
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 this twice in the thread, and this is incorrect. Actually, removing dh_testroot would be just harmful. Whether a package is to be built with R³ or not depends in most part on the builder environment, not the packaging. If you use a new enough dpkg-buildpackage, then it will enable it if the packaging allows it, otherwise it should require (fake)root; or if calling debian/rules by hand, even when the packaging has specified it can be built with no R³. (See dpkg itself for an example of this.) Thanks, Guillem
