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 "unsubscribe". Trouble? Contact listmas...@lists.debian.org
