>>"Steve" == Steve Greenland <[EMAIL PROTECTED]> writes:
Steve> On 31-Aug-00, 07:18 (CDT), Manoj Srivastava <[EMAIL PROTECTED]> wrote:
>> Firstly, build essential package is ot merrely for
>> build daemaons.
Steve> No, but I think that's the primary reason for it's
Steve> existence. If it was mainly for humans, it would be sufficient
Steve> to have checks in the in debian/rules, or a list of required
Steve> packages somewhere in README.Debian.
Hmm. Were it just the build daemons, we would not have had to
create policy and a whole package; informal arrangements would have
worked as well (there are not that many build daemons out there, and
any new one requires enough patching that coming up with a decent
list of starter packages would not be an obstacle).
The policy, and the build essential package, exists to provide
the equivalent of the essential packages for the build depends
headers, and one of the common goals of both Essential packages and
the packages listed in build essentials is to help developers
minimize the depend header lines, and it helps the special
requirements stand out.
That is where most people shall use the essential package
lists. (I am not saying, mind you, that this is the sole goal)
Steve> So I'm supposed to go back and figure out if my packages can
Steve> be successfully built with debhelper 2.0.58? If so, how can I
I think that you start with a particular version dependency,
and then only update the dependency if you use new features not
present in older helper packages.
Steve> -- is there a complete archive of all released debhelpers
Steve> somewhere? I don't think this is going to happen. Instead,
Does the changelog help?
Steve> I'll just (probably automatically) update my build-depends
Steve> line to the version of debhelper that's installed on my
Steve> machine. So the de-facto requirement is going to be "a nearly
Steve> current version of debhelper".
I beg to differ. Most people shall follow the procedure
outlined above -- start with some version of the debhelper for the
dependency, and not update that version unless you use new features.
Steve> The same is true for the build-essential packages -- nobody is
Steve> going to go back and check their stuff against old versions of
Steve> gcc and make. Admittedly, those are much slower moving
Steve> targets...but dpkg-dev isn't, necessarily.
Actually, I do have versioned dependencies on dpkg-dev, and
the process works as I outlined above -- older version of dpkg-dev
broke for my packages, and I created a versioned dependency -- and
have never had to change that, really.
Steve> But you're not running a build daemon, or otherwise trying to
Steve> build a significant number of packages from source. People
Steve> doing so are the "consumers" of Build-depends. If you were, I
Steve> don't think you'd object to being expected to having a helper
Steve> package installed (well, you might object, but the helper
Steve> packages *are* a reality, and *are* widely used).
Well, I think that these customers are so few, and need to be
quite competent, often have to have a list of packages that goes
beyon just the build essentials. We should not need a policy and a
package for just these consumers.
Our differences seem to stem from this basic difference in
opinion: whom is the build essentials package primarily for? And my
take is that the primary consumers are the developers of the 5000+
packages, and additionally, a few buld daemons, most of whom need a
core set that may not be reflected in build essentials. Your opinion,
obviously, differs.
manoj
--
All heiresses are beautiful. John Dryden
Manoj Srivastava <[EMAIL PROTECTED]> <http://www.debian.org/%7Esrivasta/>
1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
