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

Re: Upcoming FTPMaster meeting



On Mon, Feb 14, 2011 at 04:28:49PM -0800, Steve Langasek wrote:
> On Mon, Feb 14, 2011 at 09:52:32PM +0000, Roger Leigh wrote:
> > On Mon, Feb 14, 2011 at 01:08:51PM -0800, Steve Langasek wrote:
> > > And although for the most part the roll-out of multiarch is intended to be
> > > backwards-compatible and a smooth transition, there are two small extensions
> > > required to the package relationship fields in order to deploy a full
> > > multiarch stack in the archive.  The archive software doesn't need to
> > > *support* these extensions in the context of a self-hosting port, but
> > > anything that parses deps or build-deps (dak?, sbuild, wanna-build) should
> > > recognize these extensions and strip them off:
> 
> > >  - Depends: foo:any - an extension used to declare that foo of any
> > >    architecture satisfies the dependency.  The archive and official
> > >    autobuilders should treat this as equivalent to 'Depends: foo'.[1]
> 
> > sbuild switched to using Dpkg::Deps for parsing dependencies; we would
> > ideally want an equivalent to Dpkg::Deps::reduce_arch() to do the
> > stripping (if reduce_arch wasn't the appropriate place to do it
> > already).  This saves us from reimplementing yet another parser, and
> > it getting outdated; we currently use it for stripping dependencies
> > not needed for the build's architecture.
> 
> Does this need to be backported to the squeeze dpkg to be usable on the
> buildds?  I assume it will.  (I'm making my list of features we're going to
> want backported in apt/dpkg for buildds in relation to this, since we missed
> the boat by a bit for squeeze.)

Well, for Lenny we imported Dpkg::Deps into the sbuild.git tree as
Sbuild::Deps (currently on the buildd-merge2 branch; it's not in use yet,
and now squeeze is out is redundant).  We can always do the same for
Squeeze if backporting dpkg itself is not acceptable.  It will be even
easier since now the other libdpkg-perl modules it depends on won't need
importing as well.  So we have the option of importing if backporting is
not an option.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux             http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?       http://gutenprint.sourceforge.net/
   `-    GPG Public Key: 0x25BFB848   Please GPG sign your mail.

Attachment: signature.asc
Description: Digital signature


Reply to: