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

Re: Architecture: all (was Re: dh $@ --with cli --with python2 --parallel)



Hey,

On Thu, Sep 08, 2011 at 03:18:19PM +0200, Mathieu Malaterre wrote:
> On Thu, Sep 8, 2011 at 2:54 PM, Chow Loong Jin <hyperair@ubuntu.com> wrote:
> > On 08/09/2011 20:42, Mathieu Malaterre wrote:
> [...]
> >> I was told that my arch should not be set to all since mono is not
> >> available on -say- hppa. Policy requires it should be 'any' (*) ?
> >> (*) http://pkg-mono.alioth.debian.org/cli-policy/ch-packaging.html#s-architecture
> >
> > According to your link, -cil packages with 100% managed code (i.e. only
> > .dll/.exe files to be used with mono), architecture should be set to all. And
> > that is the case for libgpod-cil.
> >
> > However, it's not the same for your package, as you have some .so files inside
> > your -cil packages, so you'd have two options:
> > - Split out the glue libraries in the -cil package (.so files?) into a
> >  separate, Arch: any package.
> 
> That will not change anything AFAIK. my -cil package will Requires: a
> package that will not be available on mips, mipsel, sparc64 ...

Thus you won't be able to install it where it wouldn't work. That's
right and how most of our packages work currently. There's no guarantee
that architecture independent packages will be available on every Debian
port, only that when they are available (installable) that they then
function correctly.

> 
> > - Keep your architecture narrowing as is, and forget what I mentioned about
> >  shifting the mono-specific build-deps to Build-Depends-Indep. dh_listpackages
> >  should list -cil packages for the relevant architectures, so the example
> >  debian/rules snippet I previously posted should work.
> 
> Basically my question was that any new arch added to ports that does
> not support mono (*) needs to be explicitely added in my control file.
> I wanted to have something more ''system-based inspection" to
> determine whether or not to build the -cil package.

Either

 a) Continue building your binding packages only where mono is available
    and play catch up with mono's arch list if & when it changes
 b) Do the split so you can have mono package in b-d-i (but then you end
    up with a package for a private library which isn't that desirable).
	Or I suppose you could maybe build your gluelibs in a private
	directory in the main library runtime package.

Cheers,

-- 
Iain Lane                                  [ iain@orangesquash.org.uk ]
Debian Developer                                   [ laney@debian.org ]
Ubuntu Developer                                   [ laney@ubuntu.com ]
PhD student                                       [ ial@cs.nott.ac.uk ]

Attachment: signature.asc
Description: Digital signature


Reply to: