Bug#570934: [DPKG-DEB] possibility to hook a program at the start of dpkg-deb --build
Hi! On Mon, 2010-02-22 at 12:11:53 +0100, Raphaël Hertzog wrote: Package: dpkg Version: 1.15.6 Severity: wishlist Given that Debian packages are not all built with the same helper in debian/rules, it's difficult to hook something in the build process of all packages. debuild offers hooks at various places before/after each debian/rules call but it might not be enough in some cases. In particular, one might want to hook a program just before dpkg-deb --build does its work of creating the .deb file. It should be able to do some modifications (recording build information in the package for example) or it could only do some analysis/information gathering. Since we don't want to modify the source package at all, we should probably use an environment variable to indicate what program has to called. Since it might do modifications, dpkg-deb should be verbose and indicate what program it has called as part of the hook. This interface does not feel right for dpkg-deb, which should be considered the equivalent of a low-level archiver like zip or similar. In addition such an interface cannot be expected to be used realiably by maintainers for all builds of their packages on buildds and similar or user systems, as it needs an additional setup step. At the point the build needs the builder to setup the environment variable, other more standard options can be used instead, like placing a wrapper in /usr/local/bin/dpkg-deb, dpkg-divert'ing, etc. As such, I think this wishlist should be closed. thanks, guillem -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#570934: [DPKG-DEB] possibility to hook a program at the start of dpkg-deb --build
Hi,
On Fri, 12 Aug 2011, Guillem Jover wrote:
In addition such an interface cannot be expected to be used realiably
by maintainers for all builds of their packages on buildds and
similar or user systems, as it needs an additional setup step.
It's definitely not meant for maintainers... but it can be very useful
for derivatives distributions. I believe Ubuntu is doing stuff like
this with their pkgbinarymangler: for instance moving .mo files in
their language packs.
This precise wishlist is also a follow up of a discussion with a Maemo
developer who was looking for something similar.
It could also be useful for Emdebian to strip documentation at build time,
etc.
At the point the build needs the builder to setup the environment
variable, other more standard options can be used instead, like
placing a wrapper in /usr/local/bin/dpkg-deb, dpkg-divert'ing,
etc.
All those options need to implement the same option parsing logic than
dpkg-deb. While it's probably not hard, it's also busy work that can be
easily avoided.
I don't really see what's bad with this wishlist. If the environment
variable is not good, we can certainly consider a command line option
with a new /etc/dpkg/dpkg-deb.conf{,.d}. That would be cleaner indeed
as it allows to have several scripts invoked in the hook just like
dpkg --pre-invoke/--post-invoke.
(With the configuration file, it would also make it dead easy for a
derived distribution to use xz compression by default everywhere.)
Would the command-line option + config file approach be more acceptable to
you? I believe it's important to provide a clean way for others to do that
kind of customizations.
Cheers,
--
Raphaël Hertzog ◈ Debian Developer
Follow my Debian News ▶ http://RaphaelHertzog.com (English)
▶ http://RaphaelHertzog.fr (Français)
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#570934: [DPKG-DEB] possibility to hook a program at the start of dpkg-deb --build
On Fri, 2011-08-12 at 14:35:58 +0200, Raphael Hertzog wrote:
On Fri, 12 Aug 2011, Guillem Jover wrote:
In addition such an interface cannot be expected to be used realiably
by maintainers for all builds of their packages on buildds and
similar or user systems, as it needs an additional setup step.
It's definitely not meant for maintainers... but it can be very useful
for derivatives distributions.
Sure, was just mentioning to explicitly point out where that interface
is not that useful. And in the particular Fink case were you brought up
this bug report, I don't see why this is needed at all. They have their
own build recipes, the users are building those on their own system a
la Gentoo, so they'd need to use the “maintainer way”. In this case
dpkg-deb is being called from Fink itself, so instead of modifying Fink
to set the environment and calling some external script, they might as
well just hook whatever they need to do directly into Fink itself.
I believe Ubuntu is doing stuff like
this with their pkgbinarymangler: for instance moving .mo files in
their language packs.
I've always thought that was a hack, but not just the implementation,
the whole concept of modifying externally (to the packaging) the
binary packages during the build process. I think what they are trying
to fix should be fixed elsewhere, but of course this is the easiest
way.
It also makes their packages more tricky to reproduce as you need
more environment (and packages) setup/installed to get there.
This precise wishlist is also a follow up of a discussion with a Maemo
developer who was looking for something similar.
It could also be useful for Emdebian to strip documentation at build time,
etc.
In any case I'm not denying it could be useful, just that not all
useful things are correct things to implement.
At the point the build needs the builder to setup the environment
variable, other more standard options can be used instead, like
placing a wrapper in /usr/local/bin/dpkg-deb, dpkg-divert'ing,
etc.
All those options need to implement the same option parsing logic than
dpkg-deb. While it's probably not hard, it's also busy work that can be
easily avoided.
Just checking for -b/--build (being second or third to last argument)
and validating the arguments should be enough I'd say, and that should
be minor compared to any mangling or action the “hook” would be doing,
I don't see how that can be called busy work, it's not something you
have to do every day anyway, or commonly really.
I don't really see what's bad with this wishlist. If the environment
variable is not good, we can certainly consider a command line option
with a new /etc/dpkg/dpkg-deb.conf{,.d}. That would be cleaner indeed
as it allows to have several scripts invoked in the hook just like
dpkg --pre-invoke/--post-invoke.
Heh, I also had a paragraph about configuration files being something
that dpkg-deb should not really have at all. For the same reason you'd
not request a configuration file for something like gzip or cp.
The difference between dpkg and dpkg-deb, and why one has
configuration files and command hook support, is that the former has
state and when you perform actions they are persistent, dpkg-deb works
on different “state” every time, and as such is ephemeral.
(With the configuration file, it would also make it dead easy for a
derived distribution to use xz compression by default everywhere.)
I think I've mentioned this before, but the correct solution for a
derivative wanting to change the default compression method would be
to add a configure time switch for that.
Would the command-line option + config file approach be more acceptable to
you? I believe it's important to provide a clean way for others to do that
kind of customizations.
So while I think cattering for derivatives' needs or for that matter any
users external to Debian is important, and I think I'm always open and
have those in mind, that does not mean anything they request or that
might directly map to what they are currently doing should be accepted,
sometimes there might be better ways to implement things, that might
even benefit others, etc. Some others the correct way is just to modify
every an each package, but that's a general downside/weakness (or an
advantage depending on the situation!) of the “design” of how we handle
our source packages. Compare with the explicitly designed centralized
nature of for example ebuilds, rpm spec files or BSD ports. Trying to
bolt in the same concept on how things are done in the .deb world
seems like a forced afterthough to me.
But I guess the main contention here is that I disagree this is a
“customization” that should be allowed at this level, the usage
patterns for it seems like hacks, and as such I'd rather keep them
explicitly as what they are, which something like a wrapper does.
regards,
guillem
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of
Bug#570934: [DPKG-DEB] possibility to hook a program at the start of dpkg-deb --build
Package: dpkg Version: 1.15.6 Severity: wishlist Given that Debian packages are not all built with the same helper in debian/rules, it's difficult to hook something in the build process of all packages. debuild offers hooks at various places before/after each debian/rules call but it might not be enough in some cases. In particular, one might want to hook a program just before dpkg-deb --build does its work of creating the .deb file. It should be able to do some modifications (recording build information in the package for example) or it could only do some analysis/information gathering. Since we don't want to modify the source package at all, we should probably use an environment variable to indicate what program has to called. Since it might do modifications, dpkg-deb should be verbose and indicate what program it has called as part of the hook. Cheers, -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
