Re: Bug#374029: Fixing inconsisten and unusefull Build-Depends/Conflicts definition
Wouter Verhelst <wouter@debian.org> writes:
> On Tue, Jun 20, 2006 at 07:52:01PM -0700, Thomas Bushnell BSG wrote:
>> Stephen Gran <sgran@debian.org> writes:
>>
>> > This one time, at band camp, Thomas Bushnell BSG said:
>> >> Wouter Verhelst <wouter@debian.org> writes:
>> >>
>> >> > Sbuild explicitely, by design, only looks at build-depends. So in order
>> >> > for build-depends to be useful at this time if you want a package to
>> >> > build, you need to list mostly everything in build-depends right now
>> >> > anyway.
>> >>
>> >> Isn't it sbuild's job to comply with policy, not the other way round?
>> >
>> > Isn't it policy's job to reflect best current practice, not dictate it?
>>
>> Whenever this has been asked in the past, sbuild has simply declared
>> "this is how I want to do it." I have no idea why.
>
> The only reason why we need sbuild in the first place is that we want to
> build architecture-dependent packages on all architectures, not just the
> one the original developer uploaded a package for.
>
> For that, we need to install build-dependencies. We don't explicitely
> need all build-dependencies; we don't care about those that don't get
> used in a "dpkg-buildpackage -B" run, but we do need all those that do.
> Thus, there is a need for a split between build-dependencies that are
> needed to build architecture-dependent packages, and build-dependencies
> that are needed to build architecture-independent packages.
But architecture independent package _ARE_ build. The build target is
called. They aren't installed or packages (binary-indep isn't called)
but that is not the time expensive part usualy.
> Policy currently tries to explain that without explicitly mentioning the
> above call. I think it does so properly, but that may not be the
> case--and I'm not a native English speaker, so that may be playing with
> me a bit, too.
Policy says Build-Depends-Indep must be installed for the build
target, which sbuild calls. But sbuild does not install
Build-Depends-Indep. Same goes for dpkg-checkbuildep -B, it does not
test for Build-Depends-Indep while build will always be called.
At a minimum policy has to reflect that anything already needed for
the build target is in Build-Depends while only the actual *-indep
targets and binary require Build-Depends-Indep.
> However, since all this was invented and written precisely to accomodate
> sbuild, it would be madness to suddenly change everything because it
> seems more aesthetic (or so), and then require that sbuil jump through
> hoops to accomodate the aestethic feelings of one particular developer.
> That would be the world upside-down.
The idea is to improve sbuild, dpkg-buildpackage, debuild, pbuilder,
cowbuilder, lvmbuilder, .... with a simple change. I would hardly call
adding an (two) extra build relationship field jumping through
hoops. Sbuild already has to deal with multiple fields, one more is
not gonna hurt. And it is not just my aestethic feeling that finds the
current situation suboptimal. A lot of people have complained about
the issue and there are solid technical reasons for the change.
>> If there is no technical reason for sbuild to behave this way, and if
>> it does not in fact conform to policy, how about making it do the
>> right thing?
>
> It does do the right thing.
But it doesn't do the best thing (and currently can't).
MfG
Goswin
Reply to: