reopen 402331
thanks

On Wed, Dec 13, 2006 at 07:40:46PM -0600, Jon Marler wrote:
> The way qmail works in Debian is a hack.  It's ugly, and it's not the most
> graceful thing, but it works.  You both seem like smart guys, and I'm sure you
> can figure out how to add a user.  I'm not the one who wrote qmail such that 
> it
> requires specific users to be present before you build, hardcoding the 
> uid/gid's
> into the compiled package, that was DJB.  If you install qmail-src, or 
> manually
> add the users, the package builds fine.

$ dpkg-buildpackage -rfakeroot -B -uc -us
[...]
( ./auto-uid auto_uida `head -1 conf-users` \
        &&./auto-uid auto_uidd `head -2 conf-users | tail -1` \
        &&./auto-uid auto_uidl `head -3 conf-users | tail -1` \
        &&./auto-uid auto_uido `head -4 conf-users | tail -1` \
        &&./auto-uid auto_uidp `head -5 conf-users | tail -1` \
        &&./auto-uid auto_uidq `head -6 conf-users | tail -1` \
        &&./auto-uid auto_uidr `head -7 conf-users | tail -1` \
        &&./auto-uid auto_uids `head -8 conf-users | tail -1` \
        &&./auto-gid auto_gidq `head -1 conf-groups` \
        &&./auto-gid auto_gidn `head -2 conf-groups | tail -1` \
        ) > auto_uids.c.tmp && mv auto_uids.c.tmp auto_uids.c
fatal: unable to find user alias

This is building qmail-src from source.  Why does dpkg-buildpackage need to
touch the upstream build rules *at all*?  I haven't asked to build a qmail
binary package, only to build the packages listed in debian/control.

I can understand that one might have to install the qmail-src binary
package to create the 'alias' user before being able to build a *qmail*
binary package.  That doesn't explain why it's needed in order to build a
*qmail-src* binary package, which in spite of being arch: all, seems to
involve an awful lot of compilation!

It should be possible to rebuild the qmail-src binary package from source
without having to first install qmail-src itself.  The problem seems to be
that your debian/rules is misusing the binary-arch and binary-indep targets
for purposes other than building the packages listed in debian/control.
That's not really an upstream bug, it's a bug in the qmail packaging, and
one that makes it substantially harder for anyone to NMU this package.
However unlikely it might be that we would have security NMUs for non-free
packages, non-free packages still need to meet a minimum standard to be
included in a stable release, and I'm not sure whether or not this current
qmail build system does.

I am certain that it's a violation of policy 4.9:

          The `binary' target must be all that is necessary for the user to
          build the binary package(s) produced from this source package.

So I'm reopening this report, because it is a bug for this package to not
comply with policy.  Whether it's release-critical or not is something that
we can discuss further.

Thanks,
-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
[EMAIL PROTECTED]                                   http://www.debian.org/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Reply via email to