FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Development

 
 
LinkBack Thread Tools
 
Old 12-07-2011, 10:41 PM
Arno Tll
 
Default 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 long run, except
> maybe the first - but I quite like this feature as it is), embrace
> it, and extend it.

I am one of those who see the upsides of this change as well.

There are quite a few limitations in dh_install you can come over by
using such a script in a yet semi-expected behavior as you get a
well-defined output to anyone trying to understand a foreign package.

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. Renaming files and
multi-arch support is what comes me in mind immediately.

Gergely's idea to support standardized scripts to be executed also
sounds like a good idea.

That said, I'd appreciate if we could limit the usage to scripts in a
more sane dimension. For example for dh_install only (I fail to see how
it would be useful to other debhelper scripts - does any of you see a
legit use case for another debhelper script?), and, most important, if
we could limit this behavior to debhelper compatibility level 9 to not
break any existing source package out there which might accidentally
have +x on such a file.



- --
with kind regards,
Arno Tll
IRC: daemonkeeper on Freenode/OFTC
GnuPG Key-ID: 0x9D80F36D
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJO3/m5AAoJEMcrUe6dgPNtHjEQAI1+wFJADokc1VdY7L/miCIt
1ISaSWceOK1CHMQfDg1UK6N+MueWuF/KSIdrIACprjaYA2mm67ongyNWONT1MgeM
lkkdqVeDL0LgJSSO3/DGkKNKXiAOO37j61S8aCSI/rfXVZU0WKsovUiyzv9T2EK/
IjzAKBKPCltOnqzMQMUnx91fotLD5Shh155q/rs02fB7wmN5xT1L3BTO7LLAC1Kj
DOfpRVBLucL/rK4gSFpBJ3eL3zeSqtD3PXeOaqr8j3CwECThzT9KIVjq4ZeTGs eT
ky24qDmAS0odpoEhfNXev5EsP7oysLiX61ZTgSycB4y+BssRMo 15HuJyD3KjFxvE
9LiPsYDUal2d/+Za2yDkfCMHd3aQmwn/n0SsFc1kqcgsCgX2PxL7s2w+ndAI1vYP
g0FF9sizx6HLUndC2uXP4HvupKb+1YqkH14fPBLR62cDXJNRKZ A8vcEegZ6+x/CL
M7IUhuYxoFs1jEBmSXUV5YGNvldmAdNfIObLI18wGxNVfUpahf 8/spYNxtcXFt4H
wlJkX82i/nf2XeL3R2lSGBwYy+i/fQnV2m2R+eyM2CgomYumeqE7VXT4J5H6977l
1ptPaIm8PG+wL7X0g9UP4/qgPlvRJEMzwctEBHT3EfZ3iIMuc/3Hsclyo2MV2Yv8
mOMf1H/w9T3695QS5lwC
=hmbG
-----END PGP SIGNATURE-----


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4EDFF9B9.1010609@toell.net">http://lists.debian.org/4EDFF9B9.1010609@toell.net
 
Old 12-08-2011, 03:01 AM
Chow Loong Jin
 
Default 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 allow one to do
> complicated magic, if so need be.

I would much rather prefer a substvars-ish approach, similar to what
dpkg-gencontrol does. Making .install executable at all (even if it has a
standard #! interpreter) makes things a lot harder to standardize. Like Josselin
mentioned, bonus points for implementing this in a different language for each
package.

--
Kind regards,
Loong Jin
 
Old 12-08-2011, 03:01 AM
Chow Loong Jin
 
Default 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 allow one to do
> complicated magic, if so need be.

I would much rather prefer a substvars-ish approach, similar to what
dpkg-gencontrol does. Making .install executable at all (even if it has a
standard #! interpreter) makes things a lot harder to standardize. Like Josselin
mentioned, bonus points for implementing this in a different language for each
package.

--
Kind regards,
Loong Jin
 
Old 12-08-2011, 05:53 AM
Mike Hommey
 
Default 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 planned to the config file
> format; those needing powerful syntaxes may now use a programming language
> of their choice. (Be careful aiming that at your feet.)
> Closes: #235302, #372310, #235302, #614731,
> Closes: #438601, #477625, #632860, #642129
>
> 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@/$(dpkg-architecture -qDEB_HOST_MULTIARCH)/ << EOF
> …
> EOF
> (Bonus points for implementing this in a different language for each
> package.)

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.

Mike


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20111208065319.GB4090@glandium.org">http://lists.debian.org/20111208065319.GB4090@glandium.org
 
Old 12-08-2011, 06:14 AM
Gergely Nagy
 
Default Getting dh_install to do what we need

Chow Loong Jin <hyperair@ubuntu.com> 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 simple cases simple, and would still allow one to do
>> complicated magic, if so need be.
>
> I would much rather prefer a substvars-ish approach, similar to what
> dpkg-gencontrol does. Making .install executable at all (even if it has a
> standard #! interpreter) makes things a lot harder to standardize. Like Josselin
> mentioned, bonus points for implementing this in a different language for each
> package.

I disagree. Look at dpatch. It had executable patches since the
beginning, and a standardised script from 2.0 onwards.

Too many different implementations were never a problem in that case,
and shouldn't be in this, either. I believe most of the people who do
need this kind of feature realize that reinventing the wheel would be
counter-productive, and will try to come to an agreement, and use very
similar approaches.

--
|8]


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 874nxby1oz.fsf@luthien.mhp">http://lists.debian.org/874nxby1oz.fsf@luthien.mhp
 
Old 12-08-2011, 07:04 AM
Russ Allbery
 
Default Getting dh_install to do what we need

Mike Hommey <mh@glandium.org> 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 (rra@debian.org) <http://www.eyrie.org/~eagle/>


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87ty5bv69p.fsf@windlord.stanford.edu">http://lists.debian.org/87ty5bv69p.fsf@windlord.stanford.edu
 
Old 12-08-2011, 08:44 AM
Goswin von Brederlow
 
Default Getting dh_install to do what we need

Don Armstrong <don@debian.org> 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:
>> #! /bin/sh
>> sed s/@DEB_HOST_MULTIARCH@/$(dpkg-architecture -qDEB_HOST_MULTIARCH)/ << EOF
>> ?
>> EOF
>
> Although, honestly, you could always do this in debian/rules with
>
> override_dh_auto_install:
> debian/libfoo.install.sh > debian/libfoo.install
> dh_install;
>
> so besides the breakage generated by extraneously executable
> libfoo.install files, not much has changed in terms of obfuscation.
> That said, explicitly calling the appropriate script to generate the
> install file before the various dh_* bits were engaged is a bit
> clearer.
>
>
> Don Armstrong

Or for the more general case:

override_dh_auto_install:
debian/libfoo.my-install-script

At least with an override it would be clear from debian/rules that there
is more going on there than just copying a few files.

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.

MfG
Goswin


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87pqfz4cto.fsf@frosties.localnet">http://lists.debian.org/87pqfz4cto.fsf@frosties.localnet
 
Old 12-08-2011, 08:49 AM
Goswin von Brederlow
 
Default Getting dh_install to do what we need

Arno Töll <debian@toell.net> 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. Renaming files and
> multi-arch support is what comes me in mind immediately.

Yes, there are cases where dh_install isn't the tool you should or even
can use.

But that is what override is for. All this feature does it replace an
override for dh_install with one to chmod +x the script.

MfG
Goswin


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87liqn4clv.fsf@frosties.localnet">http://lists.debian.org/87liqn4clv.fsf@frosties.localnet
 
Old 12-08-2011, 09:03 AM
Gergely Nagy
 
Default Getting dh_install to do what we need

Goswin von Brederlow <goswin-v-b@web.de> writes:

> Arno Töll <debian@toell.net> 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. Renaming files and
>> multi-arch support is what comes me in mind immediately.
>
> Yes, there are cases where dh_install isn't the tool you should or even
> can use.
>
> But that is what override is for. All this feature does it replace an
> override for dh_install with one to chmod +x the script.

To be honest, I find executable debhelper files far cleaner and more
understandable than a maze of overrides in something that is very far
from your old trusty Makefile by now.

At least, if the various tasks one wishes to do with the executable
config files is standardised one way or the other (and that can be done:
see dpatch, which provided executable patches for *years*, and we never
saw wide-spread abuse, did we?), then all it takes is having a look at
the executable config file, perhaps the manpage of the interpreter tool,
and done.

It can make perfect sense.

And in the end, I prefer this:

,----
| #!/usr/lib/debhelper/dh_subst
| debian/tmp/usr/lib/${DEB_HOST_MULTIARCH}/libfoo.so.*
| debian/${VARIANT}/foo.conf /etc/foo/
`----

Over this:

,----
| override_dh_install:
| install -d debian/libfoo0/usr/lib/${DEB_HOST_MULTIARCH}
| cp debian/tmp/usr/lib/${DEB_HOST_MULTIARCH}/libfoo.so.* debian/libfoo0/usr/lib/${DEB_HOST_MULTIARCH}/
|
| cp debian/${VARIANT}/foo.conf debian/libfoo0/etc/foo/
`----

Perhaps it is just me, but the former makes much more sense to me, and
is easier to modify, and easier to copy to other similar packages (or
even duplicate it, if one's building multiple binaries from the same
source, all of which require similar treatment).

--
|8]


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 874nxbxtvo.fsf@algernon.balabit">http://lists.debian.org/874nxbxtvo.fsf@algernon.balabit
 
Old 12-08-2011, 09:11 AM
Arno Tll
 
Default 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 find/fix a prolem in somebody elses package. The thing that
> make cdbs so bad.


I beg to disagree. You made very good example why the former (your)
approach was a black-box indeed, whereas the newer one in fact
standardizes things in parts.

See, in your case libfoo.my-install-script could be doing anything,
including but not limited to copying, moving, creating, changing a file
without any information on what's going on.
Now, by using that feature you are forced to generate a (dynamic) file
listing instead and everyone can execute that script and see the results
without /actually/ installing anything to a binary package.

Of course you could discuss whether executing scripts is necessarily a
better idea than having some semantically parsed *.install file magic
instead, but that's an implementation detail.
Up to now, you are all discussing why "chmod +x foo.install" is so much
worse than overriding dh_install by your own dark magic but you should
be realizing you just traded one black-box for another
not-so-black-but-still-very-dark-box.


- --
with kind regards,
Arno Tll
IRC: daemonkeeper on Freenode/OFTC
GnuPG Key-ID: 0x9D80F36D
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJO4I1WAAoJEMcrUe6dgPNtyWQQAMy6IsiNwK UT+iGhTa/XzL4i
Cfrr4hmOp/pxrVNrbAE7S+c4uljcDaYzWjx381SQNGD0YRFIM/yI8A5n0rmXxWCd
YP1jVgbmCRw8hI3DwJh+i2LaM7DwjtrgFu8V62AUzwVH66UsKo lw4csPFPvkfZh4
CzLQdYYcQ5aMqUY4gVFfbl7e/Zvdxj8T/QB3eKgV7BgpRxpV/EcpgSPpicIdWRxW
96kafQIJnyPF7do8DR0XzEareNCfj9jfly6DeiHbvmxeVl+qNU 0AwMqwztzdgbmc
dZfKr3RHKEX15jHwmKBWEcQ6dP2q9QiKteoKefRLNFPxBTBHG7 5tirrBGXuW673G
n9nh8masrKcKUCTbI6TO6+vNK8qe5nAECxoHhzhBx6EN99n8IV mytxarDhvU1imT
2bq1WubtNQ3dwCGWysYm9NjKMhgb5tHf+Ytd1q1UHbX0tbazAv WYUg4soduFpU9q
TMbuvNexXkw2EnBSm6s6cAYOdv99v+aFpEMoVniX+48yNo7t8q c93kFQqCOBhY3T
s3BDSAotA9gwQbVlC0SOf+QK44I+GnCnDiTeBVEPNJdVeAonyJ l07JTkXdbr7TwB
BPwVSbgn2Ugz5V6XnmrUDMdUz1GeQ8HP7loU81KENqjuVrH+PW UI1ykjMltXfO4T
Clc/Sos/fuWuA/2PRDwZ
=Vfnx
-----END PGP SIGNATURE-----


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4EE08D56.30306@toell.net">http://lists.debian.org/4EE08D56.30306@toell.net
 

Thread Tools




All times are GMT. The time now is 07:31 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org