Re: source dependencies - and recomndations
Joey Hess writes:
> Andreas Jellinghaus wrote:
> Joey said:
> > > So you think we should have a Source-Depends-i386, Source-Depends-m68k, etc
> > > fields? I guess that would work. Though perhaps there should be a
> > > Source-Depends field that is used as default if Source-Depends-<arch> is not
> > > present, so we won't always have to add a new field to each package when a
> > > new architecture is added.
> >
> > let's use "Source-Depends: " and override that with
> > "Source-Depends-<arch>:" ok ? the first will do for most packages, and
> > with i386 specials like svgalib you have to list everything in -i386.
> > Note : you have to list everything in -arch. if -arch exist, the normal
> > Source-Depends is ignored.
Here is another solution based on an idea I've got in my mind for some
time now.
If we had the ability of specifying complex logical expressions
between package's dependencies (using both AND and OR as we have now,
but also parentheses and maybe NOT/XOR/etc operators), instead of
introducing new fields for each arch, we could just write, using
virtual packages for the local processor:
Source-Depends: ( i386 , <packages-needed-on-i386> ) | ( m68k , ... )
we could even use lazy evaluation, thus having a default statement:
Depends: ( i386 , ... ) | ( m68k , ... ) | ...
this may even be useful for binary packages as a general mechanism.
But surely we would have to implement that in such a way to keep
backward compatibility.
Bill Mitchell wrote:
On Tue, 29 Jul 1997, Joey Hess wrote:
>> Steve Greenland wrote:
>> > How about not. Instead, just make the "Source-Depends:" list the tools
>> > needed to build the package *as it was built for Debian*.
>>
>> Because, the package is built differently for different architectures.
>>
>> In my example of xaos, which Source-Recommends: svgalib1 , it is not built
>> with svgalib on architectures (like m68k), that don't have svgalib.
[...]
> It would seem, then, that Depends vs. Recommends split is not sufficiently
> explicit. The i386 autocompiler and the m68k aqutocompiler both need
> their own explicit set of Depends entries. Given that, and the policy
> that the purpose of all of this is to make it clear how to build the
> package as it was built for Debian, it seems that the need for Recommends
> disappears.
If we use Source-Depends and Source-Recommends as
advertised, ie. Depends for stuff without which it won't compile, and
Recommends for stuff which will add functionalities if present,
we could additionnally use Suggests for stuff which just makes
functionnalities behave better (eg. add more performance).
[But as Andreas said, maybe it won't be really useful]
But all this could be done at very low cost by just using wrapper
packages that will install sources. Thus we'll keep the pristine
sources as part of the official source for a binary package, and we'll
be able to use all existing mechanisms (with maybe some enhancements,
as the one proposed above.
Anders Hammarquis wrote:
>Another way would be to add architecture to the version comment, so that
> you can say something like (this meaning of course depinding on libc and,
> on i386, svgalib):
>
> Source-Depends: libc (>= 6.0.0), svgalib (i386; >= 1.2.0)
This has a bit of the same idea, but may be a bit less general; anyway
it would break dpkg just as my suggestion would ;)
--
Yann Dirson <dirson@univ-mlv.fr>
alt-email:<ydirson@a2points.com>
http://monge.univ-mlv.fr/~dirson
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-request@lists.debian.org .
Trouble? e-mail to templin@bucknell.edu .
Reply to: