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

Limiting non-build-time relationships to a set of architectures?



Frans Pop <elendil@planet.nl> (09/02/2010):
> Hi Cyril,

Hello,

> So you're subscribed to d-boot now? :-)

yes, it's probably going to make things easier. :)

> On Tuesday 09 February 2010, Cyril Brulebois wrote:
> > Frans Pop <elendil@planet.nl> (09/02/2010):
> > > This format is not (yet) allowed by policy: rootskel-gtk
> > > (>=0.05) [!s390] (except for build dependencies)
> >
> > AFAICT, it just works, and not only for Build-Depends. It can't be
> > used for an arch: all package, though, since it gets substituted
> > at build time, so it probably won't do what you would want.
> 
> I know that it is going to be allowed in the future and because of
> that I don't doubt that it (mostly?) works.  But AFAIK *currently*
> it's not allowed by policy [1], except for build deps. And thus it
> should not yet be used in uploads.

Oops, indeed. Looks like I forgot about that particular point, thanks
for pointing this out. It looks like I've been taking it granted for
quite some time.


> That other packages violate policy is not really a convincing
> argument.

(Sure, it just wanted to point an existing example out.)

> A reference to an (official) statement from FTP-masters would be.

I'd rather have -policy@ folks share their mind about it. I guess
updating the Policy to allow limiting non-build-time relationships
(Depends, Recommends, …) to some architectures would be nice to
have.

I'm not sure whether warning people about the substitution which
happens at build time[1] would have its place in the Policy since that
could be considered an (dpkg-dev) implementation detail (but that can
cause some headaches).

Mraw,
KiBi.


[1] Meaning an Architecture: all package with Depends: foo [bar] will
    have foo, or won't have foo, depending on which architecture it
    will be built upon, rather than the conditional Depends stored in
    the resulting binary.

Attachment: signature.asc
Description: Digital signature


Reply to: