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

Bug#87510: PROPOSAL] Make build dependencies a MUST



On Thu, Mar 01, 2001 at 10:54:48AM +0000, Julian Gilbey wrote:
> On Thu, Mar 01, 2001 at 12:01:40PM +1000, Anthony Towns wrote:
> > On Wed, Feb 28, 2001 at 11:01:53PM +0000, Julian Gilbey wrote:
> > > I just checked: in policy 3.1.1.1, they were a MUST (section 2.4.2).
> > > I don't know when that got lost.  So we'll go back to it.
> > Must/Should/May only had given meanings in 3.2.1.0, so it was an accepted
> > amendment to change that must to a may.
> > I object, once again.
> [So I guess that we stick with debian/rules MUST be makefiles as
> well!]

Eh? Until there's an accepted amendment to change it, yes.

> Source dependencies are a requirement.  There is no reason I can think
> of for a maintainer to say "My package doesn't need to specify source
> dependencies, I am an exception to the rule."

No, they are _not_ a requirement. We can live without them. That's what
andrea's for.

> What *is* reasonable is to say "I don't yet have time to deal with
> this."

If it's reasonable to say that, then by definition they *are not*
a requirement.

I've been saying this for half a dozen messages now, and as far as I can
tell, you've been agreeing, but here it is again, shouted and with a little
star, just for kicks:

	* POLICY SHOULD DOCUMENT CURRENT PRACTICE

If it's not current policy; if people haven't gotten around to doing it yet,
then it's not appropriate for policy!

Build-depends are great. They're wonderful. Maintainers should start
using them, and autobuilders should start using them, and people should
go through lists of packages that don't have build-depends and file bug
reports with what they should have, and so on. Sure! Definitely!

But they can do that right now.

And please, go ahead! Do it! It'll make the autobuilders' lives easier,
and thus make the autobuilders more effective, and thus make testing
more effective and thus make releasing easier, and thus make the world
an infinitely better place! Wonderful! Brilliant!

And all that has *NOTHING* to do with changing them to a "MUST".

The only thing changing that requirement to a MUST buys you is an axe
to hang over peoples heads: change this or your package is chopped out
of the distribution.

> So the source dependencies are a MUST, but we don't yet file RC bugs,

By the second half of that line, the first half is completely false.

There are only two possibilities when a package violates a MUST: either
the package has to be pulled, or policy is wrong.

> probably not even normal bugs against missing source dependencies.

Then what you're saying is that policy as it stands is *precisely*
correct.

And yet you want to change it anyway.

On Thu, Mar 01, 2001 at 01:12:47PM +0100, Josip Rodin wrote:
> We can partially achieve that by allowing a range of Standards-Versions that
> packages are allowed to have in a release. So, a maintainer whose package
> doesn't have Build-Depends can leave the Standards-Version at a lower value
> until he finds time to compile the list of build-deps.

And this idea is completely wrong as well.

Policy requirements are policy requirements. You don't get to ignore
them just because you don't bother maintaining your packages.

This whole concept of "oh, sure, some of policy is release critical and
your packages will be removed if you don't comply, but other parts are
just what we'd like, and you don't really have to bother with either if
you don't want to, but we'd like you to, so just pretend we never said
any of this, but not really, alright?" is completely ridiculous and
counterproductive. Please stop proposing it already.

Cheers,
aj

-- 
Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG signed mail preferred.

``_Any_ increase in interface difficulty, in exchange for a benefit you
  do not understand, cannot perceive, or don't care about, is too much.''
                      -- John S. Novak, III (The Humblest Man on the Net)

Attachment: pgpqHu8RjDMjG.pgp
Description: PGP signature


Reply to: