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

apt-cross perl module name



I've been reconsidering the new apt-cross perl module in Emdebian SVN
(currently libaptcross-perl / AptCross::Package etc.) because it isn't
specifically "cross" - i.e. although it can aid cross building it is
useful for any other operation on a user-level apt cache for other
purposes too. It could, conceivably, be used to parse the system apt
cache (/var/cache/apt/) it would simply require the use of sudo on the
final scripts.

The module will probably remain useful after apt-cross is replaced by
cross functionality within apt because apt-cross had to replicate a lot
of apt functionality in perl to do the cross in the first place - e.g.
to provide the cache data for a rewritten "cachecompare" script in
Emdebian to fix the horrible problems with our status pages that arise
(primarily) from trying to handle `apt-cache $foo` instead of using the
difficult-to-use perl bindings from AptPkg.

The name (AptCross::) therefore needs to change before apt-cross 0.2.9
(using the new module) is uploaded to Debian and the name gets set in
stone. I may add it to CPAN in due course too.

The new module is an object-oriented (and Data::Dumper safe) interface
to the normal apt perl bindings via AptPkg:: and libapt-pkg-perl which
is derived from NorthernCross (virtuoso {Alexander Shiskin}) and using
some code from apt-rdepends {Simon Law}. i.e. it simplifies the AptPkg
interface, removes self-referenced loops and handles putting cache data
in any writable directory, not just in /var/cache/apt, to make it easier
to work with repositories or architectures that are not suitable or
not compatible for use on the main system.

It can provide access to an apt cache for sid on Etch or Etch on sid.
It can provide access to an apt cache for arm on i386 or m68k on amd64
(that's the 'cross' element showing through) or it can do any
combination of those, in any writable directory.

Data is made available via Class::Struct -
struct (AptPackage => {
               "Package" =>             ’$’,
               "Version" =>             ’$’,
               "Source" =>              ’$’,
               "Distribution" =>        ’$’,
               "Architecture" =>        ’$’,
               "Maintainer" =>          ’$’,
etc.

with a similar struct for dependencies held in an array in the main
package data. Set the $suite, the $arch and the package name in a new
AptPackage, &lookup_pkg($pkg) - simple. Also supports adding arbitrary
Apt configuration options to the cache configuration - in apt-cross
this is used to put apt-get into download-only mode by preparing a
complete command line for apt that provides all the configuration
data from the cache handled by the module so that apt-get uses
that instead of the system cache.

I'm thinking of using:
Cache::Apt::Package, Cache::Apt::Config, Cache::Apt::Lookup (following
the current naming within CPAN) in a package: libcache-apt-perl
dependent on libapt-pkg-perl.

In order to make the package available via CPAN and to avoid problems
when the apt-cross source package is finally removed after Lenny, the
package needs to be a separate source package and will therefore be
migrating within Emdebian SVN to a new directory structure suitable for
a CPAN package and then heading for unstable via the NEW queue.

I'm happy maintaining it myself in Debian and CPAN - CC'ing debian-perl
for comments on the package name etc. (I'm not subscribed to
debian-perl so please CC: me if replying from that list.)

-- 


Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/

Attachment: pgp3l1SiJBIWp.pgp
Description: PGP signature


Reply to: