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, 09:12 AM
Jon Dowland
 
Default 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 them, in the general case,
which was frowned upon by security-concious people who like automated
package testing tools.

Does that not apply here?

--
Jon Dowland


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

Jon Dowland <jmtd@debian.org> 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 packaging without first executing them, in the general case,
> which was frowned upon by security-concious people who like automated
> package testing tools.
>
> Does that not apply here?

Not really, no. At least, executable debhelper files are not worse than
the already existing hacks and the proposed override mazes.

They actually have the potential to be much more understandable.

Compared to simple, static files, they're harder to understand and
reason about. But compared to overrides, n+1 variants of them, nope,
they're not worse in any way. However, this presents us with an
opportunity to standardise, and that's great.

Also, debhelper files are considerably easier to understand, even when
executable, than the few dpatch scripts that weren't patches are.

--
|8]


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87sjkvwee6.fsf@algernon.balabit">http://lists.debian.org/87sjkvwee6.fsf@algernon.balabit
 
Old 12-08-2011, 09:59 AM
Igor Pashev
 
Default Getting dh_install to do what we need

08.12.2011 13:49, Goswin von Brederlow пишет:

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.


As for http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=632860
I ended with dh_movefiles


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4EE098A4.50105@gmail.com">http://lists.debian.org/4EE098A4.50105@gmail.com
 
Old 12-08-2011, 01:49 PM
Josselin Mouette
 
Default 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

*tadaaaa*
It would need to be a compiled program, since you can’t use scripts in
shebangs.

--
.'`. Josselin Mouette
: :' :
`. `'
`-


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 1323355743.31948.642.camel@pi0307572">http://lists.debian.org/1323355743.31948.642.camel@pi0307572
 
Old 12-08-2011, 01:52 PM
Igor Pashev
 
Default 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


*tadaaaa*
It would need to be a compiled program, since you can’t use scripts in
shebangs.



(18:52:00)
[pashev@moon:~]
# cat shbang script
#!/bin/sh

echo "$@"

#!/home/pashev/shbang

dfwuefnwiuef


(18:52:06)
[pashev@moon:~]
# ./script
./script


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4EE0CF32.9090102@gmail.com">http://lists.debian.org/4EE0CF32.9090102@gmail.com
 
Old 12-08-2011, 03:12 PM
Gergely Nagy
 
Default Getting dh_install to do what we need

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.

But even if you couldn't, there'd be a workaround:
#! /bin/sh /usr/lib/debhelper/dh_multiarchify

--
|8]


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87aa73vy93.fsf@algernon.balabit">http://lists.debian.org/87aa73vy93.fsf@algernon.balabit
 
Old 12-08-2011, 03:13 PM
Kees Cook
 
Default 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_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

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.

The debhelper config scripts do not run in the same environment as the
rules file, so none of the environment variables available there are
available to the config scripts. This means either adding "export" lines to
the rules file (which means you can't have a nice 2-line rules file), or
it means manually re-establishing the environment in the config scripts,
which seems wasteful since dh has already done all the magic to establish
the environment.

I think it would make sense to support the common case, and that appears to
be environment variable replacements (235302, 477625, 614731, 642129), with
general filtering a close second (372310, 438601, 632860).

So, how about:

- Have debhelper do the executable marking in some way. (Yet another
config to list the config scripts?) Or, I guess, just ignore this
problem since it's only a problem in source-format-1.

- Export DEB_* environment variables to the script. This really feels
like the missing piece to me.

-Kees

--
Kees Cook @debian.org


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20111208161348.GV5169@outflux.net">http://lists.debian.org/20111208161348.GV5169@outflux.net
 
Old 12-08-2011, 03:43 PM
Gergely Nagy
 
Default Getting dh_install to do what we need

Kees Cook <kees@debian.org> 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 UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87y5unui7x.fsf@algernon.balabit">http://lists.debian.org/87y5unui7x.fsf@algernon.balabit
 
Old 12-08-2011, 03:51 PM
Goswin von Brederlow
 
Default Getting dh_install to do what we need

Arno Tll <debian@toell.net> 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 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.

> 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.

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.

I'm not objecting to the magic part, I'm objecting to the black-box
part.

> 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.

> 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.

MfG
Goswin


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87iplrdn1d.fsf@frosties.localnet">http://lists.debian.org/87iplrdn1d.fsf@frosties.localnet
 
Old 12-08-2011, 04:03 PM
Joey Hess
 
Default 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
 

Thread Tools




All times are GMT. The time now is 01:01 PM.

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