[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#148932: dpkg-dev: dpkg-buildpackage -B should try build-arch target

On Mon, Apr 07, 2003 at 08:59:25PM +0200, Josip Rodin wrote:
> On Mon, Apr 07, 2003 at 08:03:18PM +0200, Bill Allombert wrote:
> > > > Firstly, a test to see if something is a makefile can be as simple as
> > > > reading the first line of the file -- does it contain #!/usr/bin/make
> > > > -f (as policy dictates in 5.2)
> > > 
> > > Wrong. Debian policy is just that, Debian policy. dpkg does not demand
> > > that debian/rules is a makefile and will not rely on make specific
> > > behaviour.
> > 
> > So make this patch Debian specific.
> Even if it's only a Debian Policy thing, it's still wrong from dpkg's point
> of view, was not intended to be done that way, and Debian doesn't need dpkg
> to enforce this wrong policy.

What is needed is a way to tell dpkg-buildpackage which interface we
support. The current debian/rules specification does not describe such
interface, so we need to design it.

AFAIU, the current debian/rules interface supposed by dpkg-buildpackage is
1) must be executable
2) must support the following argument:
3) must act suitably when called with this argument, 'suitably'
not defined for brievity.

Unfortunately, no provision has been made for extension.

Suppose, in the mathematical sense of the term, we add a new argument:
with the specification:
when debian/rules is called with argument support,
it must output the list of supported argument.

Once all debian/rules support this, we can easily add new argument
like build-arch/build-indep.

Unfortunately, before that point we have a problem: we cannot
discriminate which debian/rules support this and which do not.

Unless we relie on assumption, like debian/rules is a makefile,
or 'debian/rules support' do nothing and exit with an error if
support is not implemented.

For the purpose of Debian development, we need backward compatibility,
so we are stuck with making assumption.

On the other hand, I do not the point of view of dpkg developers as
upstream maintainers: do they want such backward compatibility.

If not the backward compatibility stuff can be in a debian specific

Bill. <ballombe@debian.org>

Reply to: