On 31-Aug-00, 07:18 (CDT), Manoj Srivastava <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> (Please do not CC me on mail sent to this list; I subscribe to and read every list I post to.)
