Re: Getting dh_install to do what we need

Goswin von Brederlow writes: >>> My implementation copies the file to the desired destination, which may >>> or may not be a good idea - I'll do some more tests to see which one's >>> less painful and more safe. >> >> That breaks -X, --fail-missing, --list-missing, --sourcedir, and --tmpdir > > T

Re: Getting dh_install to do what we need

Joey Hess writes: > Gergely Nagy wrote: >> At the moment, I have something that works like this: >> >> , >> | #! /usr/bin/dh-exec-install >> | # The next one will simply echo it back to dh_install >> | source-file /dest-dir/ >> | >> | # This one will copy the file itself, following similar h

Re: Getting dh_install to do what we need

Josselin Mouette writes: > Le vendredi 09 décembre 2011 à 11:50 -0400, Joey Hess a écrit : >> I have made hundreds of changes to debhelper that broke buggy packages >> without using compat levels; that is not what compat levels are for. > > So, breaking a dozen packages with +x on their files in

Re: Getting dh_install to do what we need

Josselin Mouette writes: > Le vendredi 09 décembre 2011 à 16:05 +0100, Gergely Nagy a écrit : >> 'lo and behold, I started implementing dh-subst, and while it's fairly >> rough and underdocumented, there's some usable code out there in my >> github repo[1]. > > If it’s a joke, it’s a bad one. >

Re: Getting dh_install to do what we need

Le vendredi 09 décembre 2011 à 11:50 -0400, Joey Hess a écrit : > I have made hundreds of changes to debhelper that broke buggy packages > without using compat levels; that is not what compat levels are for. So, breaking a dozen packages with +x on their files in debian/ is fine, but breaking 0 p

Re: Getting dh_install to do what we need

Le vendredi 09 décembre 2011 à 16:05 +0100, Gergely Nagy a écrit : > 'lo and behold, I started implementing dh-subst, and while it's fairly > rough and underdocumented, there's some usable code out there in my > github repo[1]. If it’s a joke, it’s a bad one. Two wrongs don’t make a right. We nee

Re: Getting dh_install to do what we need

Joey Hess writes: > Gergely Nagy wrote: >> At the moment, I have something that works like this: >> >> , >> | #! /usr/bin/dh-exec-install >> | # The next one will simply echo it back to dh_install >> | source-file /dest-dir/ >> | >> | # This one will copy the file itself, following similar h

Re: Getting dh_install to do what we need

Gergely Nagy wrote: > At the moment, I have something that works like this: > > , > | #! /usr/bin/dh-exec-install > | # The next one will simply echo it back to dh_install > | source-file /dest-dir/ > | > | # This one will copy the file itself, following similar heuristics as > | # dh_install:

Re: Getting dh_install to do what we need

Goswin von Brederlow writes: >>> At a glance what does this do? >> [...] >> >> It triggers my "slap the maintainer silly" button. Other than that, it's >> dead simple: copy a file from one place to the other (with possibly >> renaming the file), with the file list following the while loop. > > No

Re: Getting dh_install to do what we need

Gergely Nagy writes: > Goswin von Brederlow writes: > >>> So, in this case, the difference is negligible, both can be trivially >>> understood. >>> >>> However, it gives more flexibility to the maintainer, to do more complex >>> stuff, if so needs be. But, that won't be the common case. Why? Bec

Re: Getting dh_install to do what we need

Goswin von Brederlow writes: >> So, in this case, the difference is negligible, both can be trivially >> understood. >> >> However, it gives more flexibility to the maintainer, to do more complex >> stuff, if so needs be. But, that won't be the common case. Why? Because >> there's no point in ove

Re: Getting dh_install to do what we need

Nicolas Boulenguez writes: > 3/ The way debhelper splits its work in small tools does not always > fit the separation of human concerns. For example, the following is > IMHO more readable that generating/executing a single debian/*.install > file in which each line deals with a different library.

Re: Getting dh_install to do what we need

If I understand well, this thread deals, among other things, with different ways to transmit a variable from debian/rules to dh_install. - via override_dh_install: and command line arguments - via debian/*.install static content - via debian/*.install.in content, preprocessed (with environment vari

Re: Getting dh_install to do what we need

Peter Samuelson writes: > [Kees Cook] >> This doesn't work with source-format-1 packages without adding >> "chmod" lines for the scripted debhelper config files in the rules >> file. Perhaps this isn't a big deal since we should all be using >> source-format-3 anyway. > > We should? I prefer to

Re: Getting dh_install to do what we need

Gergely Nagy writes: > Goswin von Brederlow writes: > >>> Compared to writing overrides, it's less effort. Compared to just >>> writing the variable and expecting it to work, it's two commands more. I >>> believe that's not much. >>> >>> On the other hand, though, making it obvious that it's a s

Re: Getting dh_install to do what we need

]] Russ Allbery > Peter Samuelson writes: > > > Not for native packages. > > Not for packages in format 3.0 (quilt). > > > In both cases, execute permission in debian/ is preserved, with the > > obvious exception of debian/rules, for which dpkg-source forces the +x > > bit. > > But still, how

Re: Getting dh_install to do what we need

Peter Samuelson writes: > Not for native packages. > Not for packages in format 3.0 (quilt). > In both cases, execute permission in debian/ is preserved, with the > obvious exception of debian/rules, for which dpkg-source forces the +x > bit. But still, how do you end up with random text files

Re: Getting dh_install to do what we need

On 10/12/2011 01:36, Bernd Zeimetz wrote: > On 12/08/2011 07:00 PM, Chow Loong Jin wrote: >> On 09/12/2011 01:40, Gergely Nagy wrote: >>> Adam Borowski writes: >>> >> *tad* >> It would need to be a compiled program, since you can’t use scripts in >> shebangs. > > Wrong, you

Re: Getting dh_install to do what we need

[Bernd Zeimetz] > So there are sources which have executable debhelper files already? I > doubt it as you'd have to chmod them manually. Not for native packages. Not for packages in format 3.0 (quilt). In both cases, execute permission in debian/ is preserved, with the obvious exception of debia

Re: Getting dh_install to do what we need

On 12/09/2011 05:01 PM, Jakub Wilk wrote: > * Joey Hess , 2011-12-09, 11:50: >>> On the other hand we do have packages with executable debhelper files that >>> are NOT scripts. Debhelper currently breaks those. The execute scripts >>> feature should use a compat level. >> I have made hundreds of ch

Re: Getting dh_install to do what we need

On 12/08/2011 07:00 PM, Chow Loong Jin wrote: > On 09/12/2011 01:40, Gergely Nagy wrote: >> Adam Borowski writes: >> > *tad* > It would need to be a compiled program, since you can’t use scripts in > shebangs. Wrong, you can. >>> >>> On Linux and Hurd, yeah. >>> On kFreeB

Re: Getting dh_install to do what we need

On 12/09/2011 07:42 AM, Goswin von Brederlow wrote: > Bernd Zeimetz writes: > >> On 12/07/2011 11:47 PM, Josselin Mouette wrote: >>> Now that we’ve made incredible progress in terms of obfuscation, I’d >>> appreciate if we could have a working solution that does not require >>> scripting for

Re: Getting dh_install to do what we need

Jakub Wilk writes: > * Gergely Nagy , 2011-12-09, 16:05: >> Comments, critique, testing and whatnot is more than welcomed, feel >> free to shout my head off if you see something remarkably stupid. >> >> [1]: https://github.com/algernon/dh-subst > > As I already told you on IRC: this name (both pa

Re: Getting dh_install to do what we need

* Joey Hess , 2011-12-09, 11:50: On the other hand we do have packages with executable debhelper files that are NOT scripts. Debhelper currently breaks those. The execute scripts feature should use a compat level. I have made hundreds of changes to debhelper that broke buggy packages without us

Re: Getting dh_install to do what we need

Goswin von Brederlow wrote: > On the other hand we do have packages with executable debhelper files > that are NOT scripts. Debhelper currently breaks those. The execute > scripts feature should use a compat level. I have made hundreds of changes to debhelper that broke buggy packages without usin

Re: Getting dh_install to do what we need

* Gergely Nagy , 2011-12-09, 16:05: Comments, critique, testing and whatnot is more than welcomed, feel free to shout my head off if you see something remarkably stupid. [1]: https://github.com/algernon/dh-subst As I already told you on IRC: this name (both package name and binary name) is w

Re: Getting dh_install to do what we need

Gergely Nagy writes: > Kees Cook writes: > >> Which means I can't use DEB_HOST_MULTIARCH in the config-scripts, >> unfortunately. > > Not to worry! dh-subst will be coming in a day or two (+ NEW waiting > time), which will allow you to use DEB_HOST_MULTIARCH as you'd expect > to. 'lo and behold

Re: Getting dh_install to do what we need

[Kees Cook] > This doesn't work with source-format-1 packages without adding > "chmod" lines for the scripted debhelper config files in the rules > file. Perhaps this isn't a big deal since we should all be using > source-format-3 anyway. We should? I prefer to think of this whole debacle as yet

Re: Getting dh_install to do what we need

Goswin von Brederlow writes: >> Compared to writing overrides, it's less effort. Compared to just >> writing the variable and expecting it to work, it's two commands more. I >> believe that's not much. >> >> On the other hand, though, making it obvious that it's a script, and >> there's magic (=

Re: Getting dh_install to do what we need

Gergely Nagy writes: > Thomas Goirand writes: > >> Disclaimer: I didn't write any multiarch packaging (yet). >> >> The incentive for doing all this seems to be multiarch. Why >> instead don't we have a mechanism to have variables in >> debian/*.install instead, or a dh_helper to move things to >

Re: Getting dh_install to do what we need

Goswin von Brederlow writes: >> I'll happily use the new dh_install feature instead of whining. > > You are forgetting that there are more people than just you looking at > your package. By using an obviously verry controversial feature you will > make everybody else life more difficult. You're

Re: Getting dh_install to do what we need

Bernd Zeimetz writes: > On 12/07/2011 11:47 PM, Josselin Mouette wrote: >> Now that we’ve made incredible progress in terms of obfuscation, I’d >> appreciate if we could have a working solution that does not require >> scripting for the most trivial operations. So what remains? >> * Co

Re: Getting dh_install to do what we need

Gergely Nagy writes: > Steve Langasek writes: > >> On Thu, Dec 08, 2011 at 10:07:12PM +0100, Gergely Nagy wrote: >>> Kees Cook writes: >> >>> > Which means I can't use DEB_HOST_MULTIARCH in the config-scripts, >>> > unfortunately. >> >>> Not to worry! dh-subst will be coming in a day or two (+

Re: Getting dh_install to do what we need

On 11-12-08 at 05:48pm, Russ Allbery wrote: > Jonas Smedegaard writes: > > > Well, in a way this one is too: compat level 9 is not yet finalized, > > as I understand it. Just prematurely gotten into use due to its > > upcoming ability to handle multiarch. > > Yeah, and that was a little unfor

Re: Getting dh_install to do what we need

Jonas Smedegaard writes: > Well, in a way this one is too: compat level 9 is not yet finalized, as > I understand it. Just prematurely gotten into use due to its upcoming > ability to handle multiarch. Yeah, and that was a little unfortunate. There are packages I've not converted to multiarch

Re: Getting dh_install to do what we need

On 11-12-08 at 03:02pm, Russ Allbery wrote: > Gergely Nagy writes: > > > Apart from the reason explained in debhelper's git history, I can > > offer another: variable substitution would be an incompatible > > change, as it's perfectly legit to have '/usr/bin/${oh hai I broke > > your system}'

Re: Getting dh_install to do what we need

Gergely Nagy writes: > Apart from the reason explained in debhelper's git history, I can offer > another: variable substitution would be an incompatible change, as it's > perfectly legit to have '/usr/bin/${oh hai I broke your system}' or > '/usr/lib/${DEB_HOST_MULTIARCH}' files. > So, we'd need

Re: Getting dh_install to do what we need

Steve Langasek writes: > On Thu, Dec 08, 2011 at 10:07:12PM +0100, Gergely Nagy wrote: >> Kees Cook writes: > >> > Which means I can't use DEB_HOST_MULTIARCH in the config-scripts, >> > unfortunately. > >> Not to worry! dh-subst will be coming in a day or two (+ NEW waiting >> time), which will

Re: Getting dh_install to do what we need

On Thu, Dec 08, 2011 at 01:36:48PM -0800, Steve Langasek wrote: > On Thu, Dec 08, 2011 at 10:07:12PM +0100, Gergely Nagy wrote: > > Kees Cook writes: > > > Which means I can't use DEB_HOST_MULTIARCH in the config-scripts, > > > unfortunately. > > Not to worry! dh-subst will be coming in a day or

Re: Getting dh_install to do what we need

Thomas Goirand writes: > P.S: Is there any valid lintian clean package in the archive that doesn't > use any helper tools at all? That's would be very instructive... dpatch, for example. There are plenty of other examples in the archive. -- |8] -- To UNSUBSCRIBE, email to debian-devel-requ.

Re: Getting dh_install to do what we need

On Thu, Dec 08, 2011 at 10:07:12PM +0100, Gergely Nagy wrote: > Kees Cook writes: > > Which means I can't use DEB_HOST_MULTIARCH in the config-scripts, > > unfortunately. > Not to worry! dh-subst will be coming in a day or two (+ NEW waiting > time), which will allow you to use DEB_HOST_MULTIARC

Re: Getting dh_install to do what we need

On 12/09/2011 03:58 AM, Gergely Nagy wrote: > [...] I don't know about you [...] > If it goes down to me, I would like using install -D -m [...] manually in my debian/rules files, but as others don't, I try avoiding such hacks these days... :) Note that using the BSD install is compatible with

Re: Getting dh_install to do what we need

Kees Cook writes: > Which means I can't use DEB_HOST_MULTIARCH in the config-scripts, > unfortunately. Not to worry! dh-subst will be coming in a day or two (+ NEW waiting time), which will allow you to use DEB_HOST_MULTIARCH as you'd expect to. -- |8] -- To UNSUBSCRIBE, email to debian-dev

Re: Getting dh_install to do what we need

Kees Cook wrote: > We must be talking about separate things: Yes, there are so many ill-advised variables floating around the build system these days that I have trouble keeping them all straight. > Which means I can't use DEB_HOST_MULTIARCH in the config-scripts, > unfortunately. Happily there

Re: Getting dh_install to do what we need

Steve Langasek wrote: > Also, I'm pretty sure the *FLAGS export happens only for dh_auto_* and > not for dh itself (set_buildflags is called from > /usr/share/perl5/Debian/Debhelper/Dh_Buildsystems.pm), so it still doesn't > help when called from dh_install. joey@gnu:~/src/debhelper>grep set_build

Re: Getting dh_install to do what we need

Thomas Goirand writes: > Disclaimer: I didn't write any multiarch packaging (yet). > > The incentive for doing all this seems to be multiarch. Why > instead don't we have a mechanism to have variables in > debian/*.install instead, or a dh_helper to move things to > the multiarch folder instead o

Re: Getting dh_install to do what we need

Chow Loong Jin writes: > On 09/12/2011 02:10, Gergely Nagy wrote: >> Chow Loong Jin writes: >> See my workaround in the mail you quoted. "#! /bin/sh $PATH" should work for kFreeBSD and pretty much anything else out there too. An extra /bin/sh never hurt anybody! >>> >>> Except th

Re: Getting dh_install to do what we need

+++ Thomas Goirand [2011-12-09 02:39 +0800]: > On 12/08/2011 06:47 AM, Josselin Mouette wrote: > > Closes: #235302, #372310, #235302, #614731, > > Closes: #438601, #477625, #632860, #642129 > > > > The incentive for doing all this seems to be multiarch. It's not just multiarch. The li

Re: Getting dh_install to do what we need

On Thu, Dec 08, 2011 at 02:47:00PM -0400, Joey Hess wrote: > Steve Langasek wrote: > > While I had originally believed this to be the case when drafting > > , feedback from those > > implementing this in practice is that dh does *not* export these va

Re: Getting dh_install to do what we need

On Thu, Dec 08, 2011 at 02:47:00PM -0400, Joey Hess wrote: > Steve Langasek wrote: > > While I had originally believed this to be the case when drafting > > , feedback from those > > implementing this in practice is that dh does *not* export these va

Re: Getting dh_install to do what we need

On 12/08/2011 06:47 AM, Josselin Mouette wrote: > For those who haven’t followed, the latest debhelper upload includes the > following change: > >* Debhelper config files may be made executable programs that output the > desired configuration. No further changes are planned to the config f

Re: Getting dh_install to do what we need

On 09/12/2011 02:10, Gergely Nagy wrote: > Chow Loong Jin writes: > >>> See my workaround in the mail you quoted. "#! /bin/sh $PATH" should work >>> for kFreeBSD and pretty much anything else out there too. An extra >>> /bin/sh never hurt anybody! >> >> Except that it forces your interpreter to b

Re: Getting dh_install to do what we need

Steve Langasek wrote: > While I had originally believed this to be the case when drafting > , feedback from those > implementing this in practice is that dh does *not* export these variables, > it only passes them to autoconf. That's not correct, dh

Re: Getting dh_install to do what we need

On Thu, Dec 08, 2011 at 06:51:51PM +0100, Andreas Metzler wrote: > Josselin Mouette wrote: > [...] > > So, to sum it up. Before, you would do in debian/rules: > >sed s/@DEB_HOST_MULTIARCH@/${DEB_HOST_MULTIARCH}/ > > debian/libfoo.install.in > debian/libfoo.install > [...] > a little bit

Re: Getting dh_install to do what we need

On 12/07/2011 11:47 PM, Josselin Mouette wrote: > Now that we’ve made incredible progress in terms of obfuscation, I’d > appreciate if we could have a working solution that does not require > scripting for the most trivial operations. So what remains? > * Convincing Joey to revert this usele

Re: Getting dh_install to do what we need

Chow Loong Jin writes: >> See my workaround in the mail you quoted. "#! /bin/sh $PATH" should work >> for kFreeBSD and pretty much anything else out there too. An extra >> /bin/sh never hurt anybody! > > Except that it forces your interpreter to be written in sh, which Debian > doesn't > like[1]

Re: Getting dh_install to do what we need

On 09/12/2011 01:40, Gergely Nagy wrote: > Adam Borowski writes: > *tad* It would need to be a compiled program, since you can’t use scripts in shebangs. >>> >>> Wrong, you can. >> >> On Linux and Hurd, yeah. >> On kFreeBSD, you can't. >> >> But hey, FreeBSD folks learned about

Re: Getting dh_install to do what we need

Josselin Mouette wrote: [...] > So, to sum it up. Before, you would do in debian/rules: >sed s/@DEB_HOST_MULTIARCH@/${DEB_HOST_MULTIARCH}/ > debian/libfoo.install.in > debian/libfoo.install [...] Hello, a little bit beside the point, but since the example seems to propagate through the

Re: Getting dh_install to do what we need

Adam Borowski writes: >> > *tad* >> > It would need to be a compiled program, since you can’t use scripts in >> > shebangs. >> >> Wrong, you can. > > On Linux and Hurd, yeah. > On kFreeBSD, you can't. > > But hey, FreeBSD folks learned about basic niceties like tab completion just > last yea

Re: Getting dh_install to do what we need

On Thu, Dec 08, 2011 at 05:12:08PM +0100, Gergely Nagy wrote: > Josselin Mouette writes: > > > Le jeudi 08 décembre 2011 à 00:12 +0100, Gergely Nagy a écrit : > >> , > >> | #! /usr/bin/dh_multiarchify > >> | /usr/lib/${DEB_HOST_MULTIARCH}/* > >> ` > >> > >> The /usr/bin/dh_multiarchify

Re: Getting dh_install to do what we need

Goswin von Brederlow writes: >>> override_dh_auto_install: >>> debian/libfoo.my-install-script >> [..] >> >>> This new feature stinks of black-box magic that will make people crazy >>> trying to find/fix a prolem in somebody elses package. The thing that >>> make cdbs so bad. >> >> >> I beg t

Re: Getting dh_install to do what we need

On Thu, Dec 08, 2011 at 01:03:18PM -0400, Joey Hess wrote: > Kees Cook wrote: > > - Export DEB_* environment variables to the script. This really feels > > like the missing piece to me. > dh already does that in v9 mode. While I had originally believed this to be the case when drafting

Re: Getting dh_install to do what we need

Kees Cook wrote: > - Export DEB_* environment variables to the script. This really feels > like the missing piece to me. dh already does that in v9 mode. -- see shy jo signature.asc Description: Digital signature

Re: Getting dh_install to do what we need

Arno Töll writes: > Hello, > > On 08.12.2011 10:44, Goswin von Brederlow wrote: >> Or for the more general case: >> >> override_dh_auto_install: >> debian/libfoo.my-install-script > [..] > >> This new feature stinks of black-box magic that will make people crazy >> trying to find/fix a prole

Re: Getting dh_install to do what we need

Kees Cook writes: > - Export DEB_* environment variables to the script. This really feels > like the missing piece to me. I'd love this too. I already have a half-baked patch, implementing some generic substitution-foo that could use this (see #651393 for the details). -- |8] -- To UNSUBSC

Re: Getting dh_install to do what we need

After looking at the bugs that are solved with this change, I don't think it's an unreasonable solution. That said, I think it feels incomplete. On Wed, Dec 07, 2011 at 11:47:49PM +0100, Josselin Mouette wrote: > So, to sum it up. Before, you would do in debian/rules: > sed s/@DEB_HOST_MU

Re: Getting dh_install to do what we need

Josselin Mouette writes: > Le jeudi 08 décembre 2011 à 00:12 +0100, Gergely Nagy a écrit : >> , >> | #! /usr/bin/dh_multiarchify >> | /usr/lib/${DEB_HOST_MULTIARCH}/* >> ` >> >> The /usr/bin/dh_multiarchify script > > *tad* > It would need to be a compiled program, since you can’t u

Re: Getting dh_install to do what we need

08.12.2011 18:49, Josselin Mouette пишет: Le jeudi 08 décembre 2011 à 00:12 +0100, Gergely Nagy a écrit : , | #! /usr/bin/dh_multiarchify | /usr/lib/${DEB_HOST_MULTIARCH}/* ` The /usr/bin/dh_multiarchify script *tad* It would need to be a compiled program, since you can’t use scri

Re: Getting dh_install to do what we need

Le jeudi 08 décembre 2011 à 00:12 +0100, Gergely Nagy a écrit : > , > | #! /usr/bin/dh_multiarchify > | /usr/lib/${DEB_HOST_MULTIARCH}/* > ` > > The /usr/bin/dh_multiarchify script *tad* It would need to be a compiled program, since you can’t use scripts in shebangs. -- .''`.

Re: Getting dh_install to do what we need

08.12.2011 13:49, Goswin von Brederlow пишет: Arno Töll writes: Your own script-fu in debian/rules or external scripts isn't exactly the next best thing to read and learn how a foreign package works and there /are/ use cases where dh_install isn't flexible enough to deal with the problem by u

Re: Getting dh_install to do what we need

Jon Dowland writes: > On Thu, Dec 08, 2011 at 08:14:52AM +0100, Gergely Nagy wrote: >> I disagree. Look at dpatch. It had executable patches since the >> beginning, and a standardised script from 2.0 onwards. > > One problem with executable patches was the fact you couldn't reason > about the pac

Re: Getting dh_install to do what we need

On Thu, Dec 08, 2011 at 08:14:52AM +0100, Gergely Nagy wrote: > I disagree. Look at dpatch. It had executable patches since the > beginning, and a standardised script from 2.0 onwards. One problem with executable patches was the fact you couldn't reason about the packaging without first executing

Re: Getting dh_install to do what we need

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, On 08.12.2011 10:44, Goswin von Brederlow wrote: > Or for the more general case: > > override_dh_auto_install: > debian/libfoo.my-install-script [..] > This new feature stinks of black-box magic that will make people crazy > trying to fin

Re: Getting dh_install to do what we need

Goswin von Brederlow writes: > Arno Töll writes: > >> Your own script-fu in debian/rules or external scripts isn't exactly the >> next best thing to read and learn how a foreign package works and there >> /are/ use cases where dh_install isn't flexible enough to deal with the >> problem by usin

Re: Getting dh_install to do what we need

Arno Töll writes: > Your own script-fu in debian/rules or external scripts isn't exactly the > next best thing to read and learn how a foreign package works and there > /are/ use cases where dh_install isn't flexible enough to deal with the > problem by using the possibilities you had before. Re

Re: Getting dh_install to do what we need

Don Armstrong writes: > On Wed, 07 Dec 2011, Josselin Mouette wrote: >> So, to sum it up. Before, you would do in debian/rules: >> sed s/@DEB_HOST_MULTIARCH@/${DEB_HOST_MULTIARCH}/ >> debian/libfoo.install.in > debian/libfoo.install >> >> Now, you will do in debian/foo.install: >>

Re: Getting dh_install to do what we need

Mike Hommey writes: > Note you also need to add a chmod +x debian/*.sh in debian/rules, since > apart from debian/rules, nothing has the executable bit after > dpkg-source -x. I believe the 3.0 (quilt) format fixes this. -- Russ Allbery (r...@debian.org)

Re: Getting dh_install to do what we need

On Wed, Dec 07, 2011 at 11:47:49PM +0100, Josselin Mouette wrote: > For those who haven’t followed, the latest debhelper upload includes the > following change: > >* Debhelper config files may be made executable programs that output the > desired configuration. No further changes are plan

Re: Getting dh_install to do what we need

Chow Loong Jin writes: > On 08/12/2011 07:12, Gergely Nagy wrote: >> >> And by extend, I mean something like: >> >> , >> | #! /usr/bin/dh_multiarchify >> | /usr/lib/${DEB_HOST_MULTIARCH}/* >> ` >> >> The /usr/bin/dh_multiarchify script would do the sed magic. This would >> make the sim

Re: Getting dh_install to do what we need

On 08/12/2011 07:12, Gergely Nagy wrote: > > And by extend, I mean something like: > > , > | #! /usr/bin/dh_multiarchify > | /usr/lib/${DEB_HOST_MULTIARCH}/* > ` > > The /usr/bin/dh_multiarchify script would do the sed magic. This would > make the simple cases simple, and would still all

Re: Getting dh_install to do what we need

On 08/12/2011 07:12, Gergely Nagy wrote: > > And by extend, I mean something like: > > , > | #! /usr/bin/dh_multiarchify > | /usr/lib/${DEB_HOST_MULTIARCH}/* > ` > > The /usr/bin/dh_multiarchify script would do the sed magic. This would > make the simple cases simple, and would still all

Re: Getting dh_install to do what we need

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I am pretty sure I'll regret to comment on this thread soonish, but ... On 08.12.2011 00:12, Gergely Nagy wrote: > I'd like to offer another option: deal with it, and instead of doing any > of the above (none of which would be a good idea in the

Re: Getting dh_install to do what we need

Josselin Mouette writes: > So, to sum it up. Before, you would do in debian/rules: > sed s/@DEB_HOST_MULTIARCH@/${DEB_HOST_MULTIARCH}/ > debian/libfoo.install.in > debian/libfoo.install > > Now, you will do in debian/foo.install: > #! /bin/sh > sed s/@DEB_HOST_MULTIARCH

Re: Getting dh_install to do what we need

On Wed, 07 Dec 2011, Josselin Mouette wrote: > So, to sum it up. Before, you would do in debian/rules: > sed s/@DEB_HOST_MULTIARCH@/${DEB_HOST_MULTIARCH}/ > debian/libfoo.install.in > debian/libfoo.install > > Now, you will do in debian/foo.install: > #! /bin/sh > sed s/

Getting dh_install to do what we need

For those who haven’t followed, the latest debhelper upload includes the following change: * Debhelper config files may be made executable programs that output the desired configuration. No further changes are planned to the config file format; those needing powerful syntaxes may now