Your message dated Wed, 11 Apr 2012 06:45:40 +0200
with message-id <[email protected]>
and subject line Re: Bug#570934: [DPKG-DEB] possibility to hook a program at
the start of dpkg-deb --build
has caused the Debian Bug report #570934,
regarding [DPKG-DEB] possibility to hook a program at the start of dpkg-deb
--build
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
570934: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=570934
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
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,
--- End Message ---
--- Begin Message ---
tag 570934 wontfix
thanks
On Sat, 2011-08-13 at 06:09:52 +0200, Guillem Jover wrote:
> 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.
Closing this now.
guillem
--- End Message ---
