Re: Cdbs Features
On May 22, Wouter Verhelst wrote: > I think at this point we can recommend dh, and require debhelper (i.e., > the individual dh_* tools could be required to be part of the build > system, but how they are called can be left to a maintainer's > discretion, with the assumption that "you use dh or perhaps cdbs, except > if you're trying to develop something better, but then you still use > debhelper behind the scenes to do the low-level work" This looks reasonable to me too. (Now I am almost sold on dh, BTW.) -- ciao, Marco signature.asc Description: PGP signature
Re: Cdbs Features
On Wed, May 15, 2019 at 02:37:59PM +0900, Marc Dequènes (duck) wrote: > On the more general topic, I believe there should be room for new tools to > emerge and not-being-dh should never be a RC or even important bug. My thoughts exactly. I think at this point we can recommend dh, and require debhelper (i.e., the individual dh_* tools could be required to be part of the build system, but how they are called can be left to a maintainer's discretion, with the assumption that "you use dh or perhaps cdbs, except if you're trying to develop something better, but then you still use debhelper behind the scenes to do the low-level work" I'll note that cdbs also uses the low-level debhelper commands behind the scenes. -- To the thief who stole my anti-depressants: I hope you're happy -- seen somewhere on the Internet on a photo of a billboard
Re: Cdbs Features
Quack, On 2019-05-14 11:24, Sean Whitton wrote: Switching the entire Haskell ecosystem over to use dh would be a massive amount of work, as the new dh_haskell would need a lot of testing etc. So Haskell libraries and apps would probably have to be one of the exceptions. It took months to get somethings working for Python and Ruby and in the end years to polish all the things and migrate all packages, so it's clearly going to take quite some time. I think one of the major feature of CDBS is the way stages are grouped in make rules and you can hook onto it or even override. Coupled with patsubst it makes some kind of loops you can use to iterate over groups of packages, which is very handy when you need to build for various versions of an interpreter. So unlike DH you can really add or override parts of these loops if your package requires it. But in the end all these rules are complex to read and maintain, and if they were very useful in the past they also pushed debhelper/dh into going forward with more bold features and I don't think CDBS adds much to the table nowadays. I would also point out that the maintenance of CDBS has been on Jonas Smedegaard's shoulders for years now and it has been difficult having almost no backup (which I'm partly responsible of). I think I was mostly able to convince him we should work on a retirement plan but I've had no time to do anything about it. Bugs like #885407 and others are still around while we are close to release, thus I still think this is the best course of action. On the more general topic, I believe there should be room for new tools to emerge and not-being-dh should never be a RC or even important bug. Nevertheless I think this tool has grown well and a strong recommendation would be fine. I believe as a project we could agree on major goals around deprecating tools that lost traction and proper maintenance, old versions of the tools, old patch formats and so on, and encouraging contribution around it. We could also agree on some practice to avoid like direct source patching (especially when not on a VCS). But this way you're still free to use the patching system that suits you or build your own and suggest it to the community; that's how many of our tools were built. As for using NMU I think this is a bad idea. Even if we're supposed to care after a NMU, this is no long-term maintenance and a returning busy maintainer would not really appreciate this. I believe adoption, becoming co-maintainer or creating a team would be better if you want to make drastic changes on a package and your one-off patch lingers in the BTS. \_o< -- Marc Dequènes
Re: Cdbs Features
On Tue, May 14, 2019 at 05:35:21AM -0700, Mo Zhou wrote: > Hi, > > On 2019-05-14 07:59, IOhannes m zmölnig wrote: > > i've migrated many of my packages from cdbs to dh, but there's one > > feature which cdbs sports and which i miss strongly (at least: the last > > time i checked) in dh (so much, that i haven't converted a couple of > > packages): building of multiple "flavours". > > that is: building the same code-base multiple times, with differing > > configurations. > > Could you please provide some examples about the case you mentioned? > I need exactly the "multiple flavours" feature for at least 2 packages: "check" is compiling 2 flavours with dh: https://tracker.debian.org/media/packages/c/check/rules-0.12.0-0.1 >
Re: Cdbs Features [and 1 more messages]
Mo Zhou writes ("Re: Cdbs Features"):
> On 2019-05-14 07:59, IOhannes m zmölnig wrote:
> > that is: building the same code-base multiple times, with differing
> > configurations.
>
> Could you please provide some examples about the case you mentioned?
> I need exactly the "multiple flavours" feature for at least 2 packages:
>
> https://salsa.debian.org/science-team/blis/blob/master/debian/rules
> https://salsa.debian.org/science-team/openblas/blob/lumin/debian/rules
...
> I'm quite interested in taking a look at how cdbs deal with such case.
IOhannes m zmölnig (Debian/GNU) writes ("Re: Cdbs Features"):
> On 14.05.19 14:35, Mo Zhou wrote:
> > I'm quite interested in taking a look at how cdbs deal with such case.
>
> https://salsa.debian.org/multimedia-team/snd/blob/master/debian/rules
> https://salsa.debian.org/multimedia-team/soundscaperenderer/blob/master/debian/rules
Wow. This is like night and day. My instinct is definitely that I
don't like cdbs but omg dh needs this feature.
I looked through the src:debhelper bugs and didn't see a request for
this.
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: Cdbs Features
On 14.05.19 14:35, Mo Zhou wrote: > I'm quite interested in taking a look at how cdbs deal with such case. https://salsa.debian.org/multimedia-team/snd/blob/master/debian/rules https://salsa.debian.org/multimedia-team/soundscaperenderer/blob/master/debian/rules gfmdsrt IOhannes
Re: Cdbs Features
Hi, On 2019-05-14 07:59, IOhannes m zmölnig wrote: > i've migrated many of my packages from cdbs to dh, but there's one > feature which cdbs sports and which i miss strongly (at least: the last > time i checked) in dh (so much, that i haven't converted a couple of > packages): building of multiple "flavours". > that is: building the same code-base multiple times, with differing > configurations. Could you please provide some examples about the case you mentioned? I need exactly the "multiple flavours" feature for at least 2 packages: https://salsa.debian.org/science-team/blis/blob/master/debian/rules https://salsa.debian.org/science-team/openblas/blob/lumin/debian/rules On amd64 the two source packages will be compiled 6 times in order to produce 6 different variants. I'm quite interested in taking a look at how cdbs deal with such case. Thanks.
Re: Cdbs Features
On 13.05.19 18:22, Sam Hartman wrote: >> "Holger" == Holger Levsen writes: > Holger> - packages using cdbs. cdbs has features dh doesnt have and > Holger> I dont think it's wrong to use cdbs. ( > > Just for my information, what are the big features cdbs has that dh does > not? > i've migrated many of my packages from cdbs to dh, but there's one feature which cdbs sports and which i miss strongly (at least: the last time i checked) in dh (so much, that i haven't converted a couple of packages): building of multiple "flavours". that is: building the same code-base multiple times, with differing configurations. while it is possible to do that with dh, it amounts to either a lot of near-duplicate lines or quite some GNU make trickery, which i'd rather not spread across multiple d/rules fgamsdr IOhannes
Re: Cdbs Features
Hello Sam, On Mon 13 May 2019 at 12:22PM -04, Sam Hartman wrote: >> "Holger" == Holger Levsen writes: > Holger> - packages using cdbs. cdbs has features dh doesnt have and > Holger> I dont think it's wrong to use cdbs. ( > > Just for my information, what are the big features cdbs has that dh does > not? I don't know cdbs well, so I don't know what big features it might have that dh does not have, but I do know that the Haskell package ecosystem relies on cdbs addon code. I.e. in our d/rules we have include /usr/share/cdbs/1/rules/debhelper.mk include /usr/share/cdbs/1/class/hlibrary.mk There have been attempts to rewrite what hlibrary.mk does as a 'dh_haskell' tool. These attempts stalled. Switching the entire Haskell ecosystem over to use dh would be a massive amount of work, as the new dh_haskell would need a lot of testing etc. So Haskell libraries and apps would probably have to be one of the exceptions. -- Sean Whitton signature.asc Description: PGP signature
Cdbs Features
> "Holger" == Holger Levsen writes: Holger> - packages using cdbs. cdbs has features dh doesnt have and Holger> I dont think it's wrong to use cdbs. ( Just for my information, what are the big features cdbs has that dh does not?
