Re: Build-depends => change policy wording
Julian Gilbey <J.D.Gilbey@qmw.ac.uk> writes:
> > Why change?
> >
> > Would it be OK for the source of mount to depend on ssh? (just a realy
> > extreme example)
>
> No: ssh is not in main (it's in non-US/non-free at present, although
> it may well end up in non-US/main very soon). See policy 2.1.2 for
> the definition of the `main' section.
>
> > Source packages should also not depend on other packages with higher
> > priority, otherwise there could arise a situation where you can´t
> > build a package because you can´t build another.
>
> No, I disagree. We've discussed this before. Many of the standard
> (even Essential) programs need development programs (auto*, gcc,
> debhelper, -dev packages etc.) in order to compile them.
I see your point there. Any developement tool would have to be
priority essential to fullfill the policy. And just saying that
standard sources may not depends on optional packages doesn´t realy
make sense. We would need a complete new set of priorities for
sources. Something like mount's source isn´t essential to compile
anything, but gcc would be essential, same with debhelper.
> However, once we've got a full set of source dependencies we will be
> able to pinpoint such circular cases, though in practice they're
> probably mainly significant for porters only.
>
> > Actually checking that all sources can be build is a fulltime
> > job. There may not be any loops in the dependencies of sources (except
> > for essential and required).
>
> Why not? There's a well-known procedure called bootstrapping....
The first thing is bootstrapping. You should be able to easily see
whats needed for bootstrapping, i.e. what source is essential. gcc
would fall under that section, but not fsck. In other words essential
are all the sources that you need to have compiled somehow before you
can start using the debian sources.
Another thing are loops in general. If two packages need each other it
might become impossible for an autobuild demon to build them
correctly. As an example consider the case where a new libc is
introduced and all must be compiled for that lib. The autobuild demons
would use still not recompiled binaries/libs to build the new packages
and link them against that and then you have packages depending on two
conflicting libcs.
Having priorities for sources would capsulate sets of packages.
Another aspect of source priorities would be that autobuild demons
could build sources with higher priority first.
May the SOurce be with you.
Goswin
PS: Since sources don´t have priorities at the moment they can´t
violate he current wording of policy, so why change it?
Reply to: