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-08-2011, 04:10 PM
Adam Borowski
 
Default Getting dh_install to do what we need

On Thu, Dec 08, 2011 at 05:12:08PM +0100, Gergely Nagy wrote:
> Josselin Mouette <joss@debian.org> 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
> >
> > *tadaaaa*
> > 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 year, give them a decade or two and you'll have recursive shebangs too.

Unless we cheat and s|^#!|#!/usr/bin/env |, that is. This works.


--
1KB // Yo momma uses IPv4!


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20111208171054.GA7465@angband.pl">http://lists.debian.org/20111208171054.GA7465@angband.pl
 
Old 12-08-2011, 04:23 PM
Steve Langasek
 
Default 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
<http://wiki.debian.org/Multiarch/Implementation>, feedback from those
implementing this in practice is that dh does *not* export these variables,
it only passes them to autoconf. So the DEB_* variables are set in the
environment when debian/rules is invoked via dpkg-buildpackage because
dpkg-buildpackage itself sets them; they are not set in the environment when
debian/rules is called directly.

If dh were to export the dpkg-architecture variables by default in v9, I
think that would be a big help here.

--
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 http://www.debian.org/
slangasek@ubuntu.com vorlon@debian.org
 
Old 12-08-2011, 04:28 PM
Gergely Nagy
 
Default Getting dh_install to do what we need

Goswin von Brederlow <goswin-v-b@web.de> 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 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,
>
> The libfoo.install file can do anything too. It's an executable, which
> are turing complete.

So, neither solution is any better or worse than the other in this
regard. Both can do pretty much anything they want.

>> 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.
>
> But the debian/rules file makes it clear that there is something more
> than copying going on. It points a big fat arrow at the
> debian/libfoo.my-install-script.

So does a +x on the install script. And if it needs to do anything more
elaborate than expanding a variable or two and copying, it can be better
documented, and have a less convoluted syntax than Makefile rules.

> With the automatic execution feauture you never know if there is magic
> going on under the hood or not unless you carefully check every single
> files permissions.

ls --color debian/, or find debian/ -type f -executable give good enough
hints, in my opinion, and quickly glancing over the results is quicker
than finding your way through a bunch of overrides.

>> 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
>
> Note: With a debian.tar file you don't need the chmod I think. So
> debian/rules would give you no indication that there is a black-box
> thing happening via dh_install.

There's alredy a lot of magic happening with debhelper. If it learned to
expand variables instead of executable scripts, there'd still be
magic. Just different kind of it.

If one's curious, the answer is a find away. It's not hard. And most
executable scripts WILL be trivial. Especially if we manage to
standardise on executable-debhelper-file-helper-tool usage.

Again, look at dpatch. I belive that despite all its warts, it is a good
demonstration that executable magic stuff can be standardised.

>> 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.
>
> Let there be light.
>
> A lot of cases will also be like
>
> override_dh_auto_install:
> sed 's/@DEB_HOST_MULTIARCH@/$(DEB_HOST_MULTIARCH)/g' < debian/libfoo.install.in > debian/libfoo.install
> dh_install
>
> Something I would find more readable than libfoo.install being a executable.

And I find this more readable:

$ cat debian/libfoo.install
#! /usr/lib/debhelper/dh_subst
debian/tmp/usr/lib/${DEB_HOST_MULTIARCH}/libfoo.so.*
$

But, the good thing is: you can do either! You can opt to not make your
files executable, and do the override magic, if so you prefer. Those of
us, who hate doing that over and over again, can use convenient helper
scripts to make the executable files trivial.

--
|8]


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87pqfzug4p.fsf@algernon.balabit">http://lists.debian.org/87pqfzug4p.fsf@algernon.balabit
 
Old 12-08-2011, 04:40 PM
Gergely Nagy
 
Default Getting dh_install to do what we need

Adam Borowski <kilobyte@angband.pl> writes:

>> > *tadaaaa*
>> > 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 year, give them a decade or two and you'll have recursive shebangs too.
>
> Unless we cheat and s|^#!|#!/usr/bin/env |, that is. This works.

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!

--
|8]


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87liqnufm2.fsf@algernon.balabit">http://lists.debian.org/87liqnufm2.fsf@algernon.balabit
 
Old 12-08-2011, 04:51 PM
Andreas Metzler
 
Default Getting dh_install to do what we need

Josselin Mouette <joss@debian.org> 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 whole thread I feel the need to mention it anyway:

999 out of a 1000 library packages will not need to use tricks like
this for conversion to multi-arch. Usually a simple wildcard works:

libfoo42.install
-debian/tmp/usr/lib/lib*.so.*
+debian/tmp/usr/lib/*/lib*.so.*

libfoo-dev.install
-debian/tmp/usr/lib/lib*.so
-debian/tmp/usr/lib/lib*.a
-debian/tmp/usr/lib/pkgconfig
+debian/tmp/usr/lib/*/lib*.so
+debian/tmp/usr/lib/*/lib*.a
+debian/tmp/usr/lib/*/pkgconfig

cu andreas


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: n2a7r8-rm8.ln1@argenau.downhill.at.eu.org">http://lists.debian.org/n2a7r8-rm8.ln1@argenau.downhill.at.eu.org
 
Old 12-08-2011, 05:00 PM
Chow Loong Jin
 
Default Getting dh_install to do what we need

On 09/12/2011 01:40, Gergely Nagy wrote:
> Adam Borowski <kilobyte@angband.pl> writes:
>
>>>> *tadaaaa*
>>>> 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 year, give them a decade or two and you'll have recursive shebangs too.
>>
>> Unless we cheat and s|^#!|#!/usr/bin/env |, that is. This works.
>
> 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][2].

[1] http://lintian.debian.org/tags/script-with-language-extension.html
[2] http://www.debian.org/doc/debian-policy/ch-files.html#s-scripts

--
Kind regards,
Loong Jin
 
Old 12-08-2011, 05:10 PM
Gergely Nagy
 
Default Getting dh_install to do what we need

Chow Loong Jin <hyperair@ubuntu.com> 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][2].
>
> [1] http://lintian.debian.org/tags/script-with-language-extension.html

This is irrelevant, as it's only about the extension, and only about
scripts on the path. My proposal has no extension, and isn't on the
path, either.

> [2] http://www.debian.org/doc/debian-policy/ch-files.html#s-scripts

This also doesn't talk about restricting the #! interpreter to
binaries. The only restriction it makes is that csh scripts should be
avoided. (And that's a should, not a must)

Besides, dpatch has been using #! /bin/sh $PATH for more than 7 years
now. Please, pretty please, find a policy violation in that, and we can
suddenly break a thousand packages in one swift swing of an arm!

--
|8]


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87hb1bue70.fsf@algernon.balabit">http://lists.debian.org/87hb1bue70.fsf@algernon.balabit
 
Old 12-08-2011, 05:20 PM
Bernd Zeimetz
 
Default 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 useless change and actually
> commit something useful.
> * NMU debhelper.
> * Technical committee.
> * Fork dh_install in a new package.

It is up to you to use debhelper or not, so just use something else - you have
experience in writing tools-which-do-the-same-thing-as-existing-tools. You could
report a bug report if you don't like it, but it is up to Joey to follow it or
not. You could do a NMU if you want people to complain about your behaviour to
DAM. You could even talk to the CTTE if you want to waste more people's time.
And yes, you could even fork (its open source!) a dh_install package - or
instead of wasting ftp master resources, just ship your own dh_install script in
your debian folders.

I'll happily use the new dh_install feature instead of whining.

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


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4EE1000B.40706@bzed.de">http://lists.debian.org/4EE1000B.40706@bzed.de
 
Old 12-08-2011, 05:35 PM
Steve Langasek
 
Default Getting dh_install to do what we need

On Thu, Dec 08, 2011 at 06:51:51PM +0100, Andreas Metzler wrote:
> Josselin Mouette <joss@debian.org> 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 beside the point, but since the example seems to propagate
> through the whole thread I feel the need to mention it anyway:

> 999 out of a 1000 library packages will not need to use tricks like
> this for conversion to multi-arch. Usually a simple wildcard works:

Your estimate is off by several orders of magnitude. Out of approximately
200 libraries converted so far, I'm sure at least 6-10 of them have needed
this trick.

Usually this is because they need to create symlinks with .links files, so
you have to know the exact name, not a wildcard; or because they need to use
dh_install to move files to a directory other than where the upstream target
installs them, so they need to be able to represent the target directory
name.

--
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 http://www.debian.org/
slangasek@ubuntu.com vorlon@debian.org
 
Old 12-08-2011, 05:39 PM
Thomas Goirand
 
Default 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 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.)
>
> 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 useless change and actually
> commit something useful.
> * NMU debhelper.
> * Technical committee.
> * Fork dh_install in a new package.
>
> Any comments before someone starts doing either of these?
>
>
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 of /usr/lib (or anything you would
find a better mechanism), so that we don't have to use tricks to
make files reach the correct destination?

Putting manual efforts into moving things to the correct
multiarch folder seem to be quite annoying, the fact that
it would be in debian/rules or in debian/*.install doesn't
change much the issue: in both case we need to put efforts
into it, which can lead to all sorts of various issues which
wouldn't happen if we had the correct automation.

Comments anyone?

Thomas


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

Thread Tools




All times are GMT. The time now is 01:04 AM.

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