Re: Source-Depends? Autoreconf?

[Marc Haber]

On Sat, 2 May 2009 13:24:07 +0100, Roger Leigh 
wrote:
>I personally dislike the entire concept of "Debian-native" source packages.
>I would like it if all software in Debian had a split .orig/.diff.  Even
>for real "native" sources, it makes things like backporting, reuse by
>others, and minor fixes, NMUs etc. rather simpler to do, and you get a
>diff of the changes to boot, which makes reintegration of the changes
>less time consuming (just review and apply the diff).  Debian-native
>packages hinder collaboration and reuse by others.

Applause.

Greetings
Marc

-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#526740: ITP: bpython -- fancy curses interface to the Python interactive interpreter

[David Paleino]

Package: wnpp
Severity: wishlist
Owner: David Paleino 

* Package name: bpython
  Version : 0.7.1
  Upstream Author : Name 
* URL : http://www.noiseforfree.com/bpython/
* License : MIT/X
  Programming Lang: Python
  Description : fancy curses interface to the Python interactive interpreter

 bpython is a curses interface to the Python interpreter, and has the
 following features:
 .
   * In-line syntax highlighting.
   * Readline-like autocomplete with suggestions displayed as you type
   * Expected parameter list for any Python function. Uses pydoc to attempt to
 divine params for C functions.
   * "Rewind" function to pop the last line of code from memory and re-evaluate.
 Note: this is only really useful when laying out classes and functions,
 since a true "undo" function is impossible, so be careful when using this.
   * Send the code you've entered off to a pastebin and display the pastebin URL
 for copying, etc.
   * Save the code you've entered to a file.
   * Auto-indentation.
   * Anti-Crash Mode.

-- 
 . ''`.  Debian maintainer | http://wiki.debian.org/DavidPaleino
 : :'  : Linuxer #334216 --|-- http://www.hanskalabs.net/
 `. `'`  GPG: 1392B174 | http://snipr.com/qa_page
   `-   2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174


signature.asc
Description: PGP signature

Re: Bug#526740: ITP: bpython -- fancy curses interface to the Python interactive interpreter

[David Paleino]

On Sun, 3 May 2009 09:54:41 +0200, David Paleino wrote:

> Package: wnpp
> Severity: wishlist
> Owner: David Paleino 
> 
> * Package name: bpython
>   Version : 0.7.1
>   Upstream Author : Name 

Argh!

Upstream Author : Bob Farrell 

Sorry people.

-- 
 . ''`.  Debian maintainer | http://wiki.debian.org/DavidPaleino
 : :'  : Linuxer #334216 --|-- http://www.hanskalabs.net/
 `. `'`  GPG: 1392B174 | http://snipr.com/qa_page
   `-   2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174


signature.asc
Description: PGP signature

Bug#526739: ITP: libbash -- a tool that enables bash dynamic-like shared libraries

[Hai Zaar]

Package: wnpp
Severity: wishlist
Owner: Hai Zaar 


* Package name: libbash
  Version : 0.9.10b
  Upstream Author : Hai Zaar 
* URL : http://libbash.sf.net
* License : GPL
  Programming Lang: shell script
  Description : a tool that enables bash dynamic-like shared libraries

libbash is a tool for managing bash scripts that contain functions you may
want to use in various scripts. It provides mechanism to define dependencies
between scripts and facility for script loading.

-- System Information:
Debian Release: 5.0.1
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Source-Depends? Autoreconf?

[Bernhard R. Link]

* Henrique de Moraes Holschuh  [090502 18:25]:
> On Sat, 02 May 2009, Bernhard R. Link wrote:
> > First of all, you do not discuss the most common type of packages: do
> > not change the build-system, but just use it. This means autotools are
> > never called, neighter when preparing the package, nor when building the
> > package.
>
> Yeah, it is really common, and it is also close to being the 'worst
> practice' (except for the few packages whose upstream takes very good
> care of their build system and keep it up-to-date themselves).

I disagree here strongly. While many Debian developers are better at
judging and improving build systems than the average upstream,
understanding a build in all its details and important pitfalls just
needs to much experience with that specific package to be error-proof.
Thus the best way is the DD to help upstream to improve the build system
and then is using the upstream build system unmodified as long it can be
used to produce sane results. (Of course often build systems are just
too broken for that. But often the perceived need to change a build
system is just a result of understanding the tools involved. (Like often
giving make an argument makes patching a Makefile uncessary).

> > The more important goals are:
> >  - derivation from upstream:
> > + every change means using something not previously tested.
>
> Well, as a rule, we do much better at testing build systems than any
> upstream, anywhere.  We build for MUCH more platforms, for one.

We build for much more platforms, but all our platforms are quite
uniform w.r.t. things a build system usually has to deal with.
It also depends on the kind of package. Most things are just too seldom
tested in Debian package. Breaking core funcitonality or failing builds
will usually be caught well, but that is not true for anything.

For example in one package I mispatched a Makfile to support DESTDIR.
Upstream did only install a file, if it was not already there. The
install command got the DESTDIR, but the check did not. This introduces
a bug causing the file to be missing if the package is build with it
being installed. I doubt any DD would have caught it until some poor
user wanting to recompile/patch it would have been bitten by it, had
I not by cheer luck and comparing file lists all the time would have
found it.

> And
> likely we're already using a newer toolchain than upstream anyway...
> and that's far more likely to root out bogosity (or to cause bogosity
> for that matter) than autoreconf.

Well, newer for some upstreams. Older for other ones. And often both
older and newer at the same time. This only means this point is one of
many, not that it is unimportant.


> There is one _very_ important reason why it is the best practice, too:
> since the build process is complete, and tested at every upload on
> every arch, it is far less likely to break on the hands of the
> security team, or on the hands of a porter of a new arch, or in the
> hands of someone else in a time of need.

This is what I called robustness. And I fail to see how having a new
build-system every time can be more robust than using the same tested
again and again. (Unless people want to change something in the build
system, which is also an important thing to look at. Having to
change the build system in a security upload or a new arch is quite
rare (especially with autotools, which abstract architectures into
specific files), but it is also an important point, though I'd put it
into maintainability).

Hochachtungsvoll,
Bernhard R. Link


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

make-kpkg and 2.6.29.2 vanilla sources

[Raffaele Morelli]

Hi you all,

I am using vanilla sources to build a debian RT custom kernel using
make-kpkg.
Compiling goes very nice and ends up with a deb kernel package but make-kpkg
does't generate initrd using --initrd option! I had to generete it by hand
with update-initrams and the put the corresponding line to menu.lst in order
to boot.

I usually run latest stable vanilla releases and never experienced that
problem with make-kpkg.

Is it a bug or what?

regards
-r

Re: Source-Depends? Autoreconf?

[Bernhard R. Link]

* Manoj Srivastava  [090503 01:24]:
> I wold like to say that I do not really see the Degbian source
>  package as a primary mode of development  communication between Debian
>  and the downstreams, as it is strictly a snapshot, and loses too much
>  history.  I think that people deriving code based on lines of
>  development I have in my packages will be better served by using a
>  distributed VCS; and collaboration and feeback would be far easier.

For a close colloboration and joint development having history and
anything that brings the changes nearer to upstreams (having branches
in upstream's centrel VCS, or using the same distributed VCS as upstream)
is of course the way to go, and having additionally something with
history is of course always good.

But whenever I wanted to look around what other distributions did with
one of my packages, I really started to hate the "a VCS is everything
that is needed" approach. Getting lost in the CVS directories of some
*BSDs, having to deal with all kind of different VCSes like arch, bzr,
subversion, or whatever the particular distribution decided to
standardize on, having things differently everywhere and jump through
hops to just get what I'm intrested in: What is their current state?
What changes have they applied?
Then often having things practically forked, as their VCS has history,
but does not group changes. (Which if from that point of view not really
easier than having just a single monolythic patch, with the only
difference that it took hours to get that patch and with even more time
you could learn how you can see when each line was added).

> > Also assessment of external factors plays an important role. Several
> > years ago, autotools changed quite rapdily and
> > disruptively. Robustness was an important reason to not run autotools
> > while building.  Now this has changed, so running autotools at build
> > time is often considered the best solution, as it causes clean diffs,
> > well-tested build paths and easy maintanability. (Though it still
> > depends on the actual case. Very small changes, massively outdated
> > uptreams and/or usage of strange corner-cases of autotools can still
> > make something else better depending on a wide range of factors).
>
> The same might be true for any other component in the tool
>  chain, no?

Of course it is. Nothing special about autotools here, except perhaps
that you more often have the choice. You cannot add a compiler to your
package (so all you have to choose from is using the default compiler or
forcing a specific version and build-depending on that), while autotools
make it possible to have the build system there. And once you have the
choice, you need to decide what is best.

Hochachtungsvoll,
Bernhard R. Link


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#526762: ITP: pwauth -- authenticator for mod_authnz_external and the Apache HTTP Daemon

[Hai Zaar]

Package: wnpp
Severity: wishlist
Owner: Hai Zaar 


* Package name: pwauth
  Version : 2.3.8
  Upstream Author : Jan Wolter 
* URL : http://code.google.com/p/pwauth/
* License : BSD
  Programming Lang: C
  Description : authenticator for mod_authnz_external and the Apache HTTP 
Daemon

Pwauth is an authenticator designed to be used with
mod_auth_external or mod_authnz_external and the Apache
HTTP Daemon to support reasonably secure web
authentication out of the system password database on most
versions of Unix. Particulary - secure authentication
against PAM.


-- System Information:
Debian Release: 5.0.1
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: make-kpkg and 2.6.29.2 vanilla sources

[David Paleino]

On Sun, 3 May 2009 10:14:57 +0200, Raffaele Morelli wrote:

> Hi you all,
> 
> I am using vanilla sources to build a debian RT custom kernel using
> make-kpkg.
> Compiling goes very nice and ends up with a deb kernel package but make-kpkg
> does't generate initrd using --initrd option! I had to generete it by hand
> with update-initrams and the put the corresponding line to menu.lst in order
> to boot.

It's a change happened in 12.001, and sid now has 12.013:

kernel-package (12.001) experimental; urgency=low
[..]
  * Image postinst no longer runs a boot loader

Note that this was already the case for grub, one of the more popular
boot loaders.
  
Now that we have a mechanism for running arbitrary scripts when the
image packages are manipulated, we can stop embedding the boot loader
actions in the package itself. This means that lilo, elilo, etc will
no longer be run directly by the post isnt, and all the code related
to detecting the boot loader, managing the configuration, and adding
bits about bootloader documentation is all removed from the
postinst. This allows the image package to be more flexible, since the
end user is no longer restricted to the actions encoded in the image
package. This is a fairly large change.
[..]
  * The image postinst no longer runs the initramfs creation
commands. Instead, there are example scripts provided that will
perform the task. These scripts will work for official kernel images
as well.

 -- Manoj Srivastava   Wed, 01 Apr 2009 13:05:40 -0500

Kindly,
David

-- 
 . ''`.  Debian maintainer | http://wiki.debian.org/DavidPaleino
 : :'  : Linuxer #334216 --|-- http://www.hanskalabs.net/
 `. `'`  GPG: 1392B174 | http://snipr.com/qa_page
   `-   2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174


signature.asc
Description: PGP signature

Re: make-kpkg and 2.6.29.2 vanilla sources

[Bernd Zeimetz]

David Paleino wrote:

>   * The image postinst no longer runs the initramfs creation
> commands. Instead, there are example scripts provided that will
> perform the task. These scripts will work for official kernel images
> as well.

Don't use the example scripts, they're kinda weird. initramfs-tools installs
proper hooks there, at least since 0.93.2.

Cheers,

Bernd

-- 
 Bernd Zeimetz   Debian GNU/Linux Developer
 GPG Fingerprint: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#526786: ITP: libapache2-mod-authnz-external -- authenticate Apache against external authentication services

[Hai Zaar]

Package: wnpp
Severity: wishlist
Owner: Hai Zaar 


* Package name: libapache2-mod-authnz-external
  Version : 3.2.3
  Upstream Author : Jan Wolter 
* URL : http://www.unixpapa.com/mod_auth_external/
* License : Apache
  Programming Lang: C
  Description : authenticate Apache against external authentication services

Mod_Auth_External can be used to quickly construct secure, reliable
authentication systems.  It can also be mis-used to quickly open gaping
holes in your security.  Read the documentation, and use with extreme
caution.
Notably, this module can be used to securely authenticate against PAM
(without exposing /etc/shadow file).
This Package includes the mod-athnz-external Module for Apache Version 2.x

-- System Information:
Debian Release: 5.0.1
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#526790: ITP: libapache2-mod-authz-unixgroup -- access control based on on unix group membership for Apache

[Hai Zaar]

Package: wnpp
Severity: wishlist
Owner: Hai Zaar 


* Package name: libapache2-mod-authz-unixgroup
  Version : 1.0.1
  Upstream Author : Jan Wolter   
* URL : http://www.unixpapa.com/mod_authz_unixgroup/
* License : Apache
  Programming Lang: C
  Description : access control based on on unix group membership for Apache

Mod_Authz_Unixgroup is a unix group access control module for Apache 2.1 and
later. If you are having users authenticate with real Unix login ID over the
net, using something like my mod_authnz_external / pwauth combination, and
you want to do access control based on unix group membership, then
mod_authz_unixgroup is exactly what you need.

This Package includes the mod-authn-unixgroup Module for Apache Version 2.2

-- System Information:
Debian Release: 5.0.1
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Source-Depends? Autoreconf?

[Manoj Srivastava]

On Sun, May 03 2009, Bernhard R. Link wrote:


>> There is one _very_ important reason why it is the best practice, too:
>> since the build process is complete, and tested at every upload on
>> every arch, it is far less likely to break on the hands of the
>> security team, or on the hands of a porter of a new arch, or in the
>> hands of someone else in a time of need.
>
> This is what I called robustness. And I fail to see how having a new
> build-system every time can be more robust than using the same tested
> again and again. (Unless people want to change something in the build
> system, which is also an important thing to look at. Having to
> change the build system in a security upload or a new arch is quite
> rare (especially with autotools, which abstract architectures into
> specific files), but it is also an important point, though I'd put it
> into maintainability).

Having a package that only builds in a hothouse (that is, with a
 single "tested" toolchain) is actually detrimental to the quality of
 implementation. If we are trying to be a good citizen in the free
 software world, just building a binary package that happens to work on
 our buildds is just one goal. We should also seek to
  + cater to users building our software on their regular machine (not
just in artificially clean build environments)
  + Try to find out bugs in the toolchain -- and that means the
autotools too. Locking down gcc or autotools versions hinders this.

Can using whatever gcc or autotools is around sometimes uncover
 bugs and prevent building? Sure. But once found, these bugs can be
 fixed, and not just for Debian package  builders.

manoj
-- 
An engineer is someone who does list processing in FORTRAN.
Manoj Srivastava    
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: make-kpkg and 2.6.29.2 vanilla sources

[Manoj Srivastava]

On Sun, May 03 2009, Bernd Zeimetz wrote:

> David Paleino wrote:
>
>>   * The image postinst no longer runs the initramfs creation
>> commands. Instead, there are example scripts provided that will
>> perform the task. These scripts will work for official kernel images
>> as well.
>
> Don't use the example scripts, they're kinda weird. initramfs-tools installs
> proper hooks there, at least since 0.93.2.

What horrendous advice. Obviously, there was no attempt to
 actually test the advice, or even to read the hook script. And as such,
 this advice is wrong. Observe:
,
| __> dpkg -x /var/cache/apt/archives/initramfs-tools_0.93.2_all.deb root1
| __> cat root1/etc/kernel/postinst.d/initramfs-tools
| #!/bin/sh
| 
| # passing the kernel version is required
| [ -z "$1" ] && exit 0
| 
| # kernel-package passes an extra arg; hack to not run under kernel-package
| [ -z "$2" ] || exit 0
| 
| # we're good - create initramfs.  update runs do_bootloader
| update-initramfs -c -t -k "$1"
`

See where it says that this hook doe snot run under
 kernel-package images? maks has not yet had time to upload the patched
 hook (he does have other things to do, you know). Now observe the
 script below, from kernel-package.

See how it aborts when there is an indication that the
 kernel-image does not need an initrd? So that people who are compiling
 their own kernels and who do not need an initramfs are not saddled with
 one anyway?

See also that it only triggers when the maintainer script is
 called with the configure command? See how it supports, like
 kernel-package does, having your vmlinuz-* being not in .boot, but
 elsewhere? 

Weird my foot.

manoj

,
| __> cat etc/kernel/postinst.d/initramfs 
| #! /bin/sh
| 
| set -e
| 
| if [ -n "$INITRD" ] && [ "$INITRD" = 'No' ]; then
| exit 0
| fi
| version="$1"
| vmlinuz_location="$2"
| 
| 
| if [ -n "$DEB_MAINT_PARAMS" ]; then
| eval set -- "$DEB_MAINT_PARAMS"
| if [ -z "$1" ] || [ "$1" != "configure" ]; then
| exit 0;
| fi
| fi
| 
| # passing the kernel version is required
| [ -z "$version" ] && exit 1
| 
| 
| if [  -n "$vmlinuz_location" ]; then
| # Where is the image located? We'll place the initrd there.
| boot=$(dirname "$vmlinuz_location")
| bootarg="-b $boot"
| fi
| 
| # 
| if which update-initramfs >/dev/null ; then
| update-initramfs -c -t -k "$version" $bootarg
| fi
`

-- 
Conserve energy, kill yourself. j...@dscatoh0.sac.ca.us
Manoj Srivastava    
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Source-Depends? Autoreconf?

[Manoj Srivastava]

On Sun, May 03 2009, Bernhard R. Link wrote:

> * Manoj Srivastava  [090503 01:24]:
>> I wold like to say that I do not really see the Degbian source
>>  package as a primary mode of development  communication between Debian
>>  and the downstreams, as it is strictly a snapshot, and loses too much
>>  history.  I think that people deriving code based on lines of
>>  development I have in my packages will be better served by using a
>>  distributed VCS; and collaboration and feeback would be far easier.
>
> For a close colloboration and joint development having history and
> anything that brings the changes nearer to upstreams (having branches
> in upstream's centrel VCS, or using the same distributed VCS as upstream)
> is of course the way to go, and having additionally something with
> history is of course always good.
>
> But whenever I wanted to look around what other distributions did with
> one of my packages, I really started to hate the "a VCS is everything
> that is needed" approach. Getting lost in the CVS directories of some
> *BSDs, having to deal with all kind of different VCSes like arch, bzr,
> subversion, or whatever the particular distribution decided to
> standardize on, having things differently everywhere and jump through
> hops to just get what I'm intrested in: What is their current state?
> What changes have they applied?

In that case, having the sources cluttered with autotools
 changes is pretty bad. I would much rather unpack their sources, and
 run a diff -uBbwr between two source directories. In that case, not
 having the autotools in the packages is nicer.

> Then often having things practically forked, as their VCS has history,
> but does not group changes. (Which if from that point of view not really
> easier than having just a single monolythic patch, with the only
> difference that it took hours to get that patch and with even more time
> you could learn how you can see when each line was added).

You are not really about collaborating with them, you want
 really a quick diff.  For that, I suppose an uncluttered package source
 is good.

>> > Also assessment of external factors plays an important role. Several
>> > years ago, autotools changed quite rapdily and
>> > disruptively. Robustness was an important reason to not run autotools
>> > while building.  Now this has changed, so running autotools at build
>> > time is often considered the best solution, as it causes clean diffs,
>> > well-tested build paths and easy maintanability. (Though it still
>> > depends on the actual case. Very small changes, massively outdated
>> > uptreams and/or usage of strange corner-cases of autotools can still
>> > make something else better depending on a wide range of factors).
>>
>> The same might be true for any other component in the tool
>>  chain, no?
>
> Of course it is. Nothing special about autotools here, except perhaps
> that you more often have the choice. You cannot add a compiler to your
> package (so all you have to choose from is using the default compiler or
> forcing a specific version and build-depending on that), while autotools
> make it possible to have the build system there. And once you have the
> choice, you need to decide what is best.

I see adding autotools files and cluttering up a user running
 diff a bad thing, similar to (but perhaps different in degree) storing
 away a private gcc install in the binary.

manoj
-- 
Television has proved that people will look at anything rather than each
other. Ann Landers
Manoj Srivastava    
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: make-kpkg and 2.6.29.2 vanilla sources

[Bernd Zeimetz]

Manoj Srivastava wrote:
> On Sun, May 03 2009, Bernd Zeimetz wrote:
> 
>> David Paleino wrote:
>>
>>>   * The image postinst no longer runs the initramfs creation
>>> commands. Instead, there are example scripts provided that will
>>> perform the task. These scripts will work for official kernel images
>>> as well.
>> Don't use the example scripts, they're kinda weird. initramfs-tools installs
>> proper hooks there, at least since 0.93.2.
> 
> What horrendous advice. Obviously, there was no attempt to
>  actually test the advice, or even to read the hook script. And as such,
>  this advice is wrong. Observe:

[..]
ok, I stand corrected. I'm not sure anymore which script I looked into, but it
scared me away somehow. Next time I'll re-read things again...

Cheers,

Bernd

-- 
 Bernd Zeimetz   Debian GNU/Linux Developer
 GPG Fingerprint: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: make-kpkg and 2.6.29.2 vanilla sources

[Kai Wasserbäch]

Hello Raffaele,
Raffaele Morelli schrieb:
> [...]
> 
> Is it a bug or what?

No, as documented in the changelog ([0]) and probably elsewhere you need to put
the needed scripts into [1]. In case of initrd generation example scrpts are
shipped with kernel-package in [2].

I hope this helped.

Greetings,
Kai


[0]

(please note, that it is also mentioned in later changelog entries for several
reasons)
[1] 
[2] 




-- 

Kai Wasserbäch (Kai Wasserbaech)

E-Mail: deb...@carbon-project.org
Jabber (debianforum.de): Drizzt
URL: http://wiki.debianforum.de/Drizzt_Do%27Urden
GnuPG: 0xE1DE59D2  0600 96CE F3C8 E733 E5B6 1587 A309 D76C E1DE 59D2
(http://pgpkeys.pca.dfn.de/pks/lookup?search=0xE1DE59D2&fingerprint=on&hash=on&op=vindex)



signature.asc
Description: OpenPGP digital signature

Re: Environment variables, debian/rules and dpkg-buildpackage

[Guillem Jover]

[ BCCed debian-dpkg for the proposed dpkg changes. ]

Hi!

On Fri, 2009-03-13 at 21:04:30 +0100, Raphael Hertzog wrote:
> we have an unfortunate situation where the practice in dpkg-buildpackage
> and the policy do not match fully.

Ok, had finally the time to read and think about this. I've to say first
of all that I've never quite liked dpkg-buildpackage as a way to set
distro-wide flags, and less so by doing it by default and kind of
deprecating debian/rules in the way. But at the time this got implemented
I didn't have the time to ponder about better alternatives or discuss
about it (although the makefile include crossed my mind at some point,
and we talked about it with Raphaël before he started this thread).
In retrospect I guess I should have chimed in on the initial discussion
or the subsequent complaints, but nothing that cannot be repaired now
anyway.

I'll try to summarize the discussion (althought it might be biased to
my preferred option) and some facts, so that we can get to a conclusion:

* We'd like to have at least this overriding hierarchy (the
  implementation could be a bit more complex, but I think that's
  not important now, as this one already exposes problems in the
  dpkg-buildpackage proposal):

  - Distro defaults.
  - Site overrides over the above (can be partial filters).
  - Package overrides over the above (can be partial filters).
  - User overrides over the above (total overrides).

* dpkg-buildpackage currently sets the build flags through env vars.

* Lots of packages (roughly around 4k) do not honour env vars for build
  flags, as they follow the examples from policy (or dh-make and similar)
  and thus are setting them unconditionally, which env vars do not
  override.

,-- chk-flags --
#!/bin/sh
set -eu
regex="$@"
cd /srv/lintian.debian.org/laboratory/source/
ls | xargs -I% grep -H -l "$regex" %/debfiles/rules | wc -l
`--

  ./chk-flags '^[^#]*\(CXX\|F\|CPP\|LD\|C\)FLAGS[[:space:]]*:\?='

* Thus lots of packages in the archive have to be modified anyway
  regardless of either solution (centralization through dpkg-buildpackage
  or makefile include). If we have to modify them, we can make them
  include a makefile. Adding such include line at the top of debian/rules
  should certainly imply less changes than the proposed changes in
  .

* dpkg-buildpackage has been setting env vars for dpkg-architecture
  output for a long time (2001), but those flags are a bit different
  than the other build flags. First the example code in dh-make uses ?=
  which makes the env vars take preference, and they are (or should be)
  always initialized in the debian/rules file as recommended by
  dpkg-architecture(1). And second the *_BUILD_* ones should alway match
  the current system, and the *_HOST_* ones should be changed by
  changing the toolchain, so there's no reason to override them in the
  distro or packaging (if there's a need then dpkg should be fixed
  instead).

* Externalizing the setup of the build flags means that debian/rules
  stops being a working standalone interface for building packages, as
  mandated by policy, and imposes an additional layer to rely on for
  building packages

* Setting system (distro and site) build vars through command line (or
  forced environment 'make -e') does not allow the pkg to override them,
  nor do partial filtering.

* Using 'make -e' is not really a good idea as it's not fine grained. So
  the correct solution when total override is desired is to set the
  vars via the command line.

* Setting system (distro and site) build vars through command line,
  implies we can only use limited make syntax for those vars.

* We can set the architecture and default flags (from policy) on the
  makefile to be included, and packagers will be able to do the change
  and fix any possible problems (progressive opt-in), but once it's
  included by all packages, then we can do system-wide default changes
  in the same we change toolchains (mass rebuild, bug filing, change
  when bug count goes down). The makefile has the advantage that the
  distro default can be temporarily changed for the mass build w/o
  needing to totally override the build flags.


So I think for next dpkg upload we should make dpkg-buildpackage stop
setting any flags by default, and switch the setting to go through the
command line arguments to override the package options instead of the
environment, so this would become the user override part. The DEB_VENDOR
env var should not be set either, and we should work on getting a
dpkg-vendor instead, before people try to start using the variable.


Then if we get consensus that this is the righ path, agree on the
makefile names (as once decided it will be a pain to change later on in
all packages), we'll need to ship the distro defaults file somewhere and
start fixing packages to include that makefile. The files could look
something like:

,-- /usr/share/dpkg/build-options.mk