Re: Bug#70269: automatic build fails for potato

[Steve Greenland <stevegr@debian.org>]

On 31-Aug-00, 07:18 (CDT), Manoj Srivastava <srivasta@debian.org> wrote: 
> 	Firstly, build essential package is ot merrely for
>  build daemaons. 

No, but I think that's the primary reason for it's existence. If it
was mainly for humans, it would be sufficient to have checks in the in
debian/rules, or a list of required packages somewhere in README.Debian.

> Therefore packages would need to specify the oldest version of the
> build package they can be built with (in the worst case, exactly the
> version they were built with), since not every machine they can be
> built on can be depended to ahve the altest version of the helper
> packages.

So I'm supposed to go back and figure out if my packages can be
successfully built with debhelper 2.0.58? If so, how can I -- is there
a complete archive of all released debhelpers somewhere? I don't think
this is going to happen. Instead, I'll just (probably automatically)
update my build-depends line to the version of debhelper that's
installed on my machine. So the de-facto requirement is going to be
"a nearly current version of debhelper". The same is true for the
build-essential packages -- nobody is going to go back and check their
stuff against old versions of gcc and make. Admittedly, those are much
slower moving targets...but dpkg-dev isn't, necessarily.


> Indeed, none of may machines have _any_ helper packages
> installed. 

But you're not running a build daemon, or otherwise trying to build a
significant number of packages from source. People doing so are the
"consumers" of Build-depends. If you were, I don't think you'd object
to being expected to having a helper package installed (well, you might
object, but the helper packages *are* a reality, and *are* widely used).


>  I think that since every package using a helper package seems
>  to need a versioned dependency, addign debhelper to build essential
>  shall not remove the burden from the packages.

Mine don't. Or rather, the version needed is sufficiently old that I
have no idea what it might be. 

Hmmm, let me ammend that. To comply with *current* policy, I need a
(nearly) *current* version of debhelper. But my package builds won't
fail with an older version, and someone with an older version is
probably running an old system under old policy. One could argue that
this is a *good* thing -- if someone wants to build a woody+1 version of
cron on slink, isn't it better that they get slink-consistent handling
of /usr/doc vs. /usr/share/doc?

>  And auto build daemons
>  can also augment the build environment beyond build essential, as
>  they already do.

Of course. My point is *exactly* that any build daemon (or other
significant beneficiary of build-depends) *must* have debhelper
installed, so why not make it build-essential? 
 
> 	Am I missing the mark here?

I think we may just have to different conclusions from the same base
facts. This is not necessarily unreasonable. In particular, I don't buy
into the "debhelper requires versioned dependencies" argument. I think
*if* a package needs a specific version of debhelper it would be fine to
put it into the build-depends list. I also think it's reasonable to say
"the current version of debhelper is build-essential".

Steve

-- 
Steve Greenland <stevegr@debian.org>
(Please do not CC me on mail sent to this list; I subscribe to and read
every list I post to.)


-- 
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org