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

Re: Bug#70269: automatic build fails for potato



>>"Steve" == Steve Greenland <stevegr@debian.org> writes:

 Steve> On 31-Aug-00, 07:18 (CDT), Manoj Srivastava <srivasta@debian.org> 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   <srivasta@debian.org>  <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


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


Reply to: