Hello all,

as you probably already know, britney (the testing migration script) is
using a local customized dpkg source to test the installability of a
package while updating the testing distribution.

This is not really easy to manage, and in fact the code is quite complex to
maintain and debug. I'm sure that it would be possible to use dpkg
directly, and this would help a lot the release team maintaining britney
without taking care of the details for the installability check. The
problem is that I don't know at all the dpkg internals and I have no idea
about the parts of the dpkg source code which should be exposed to britney
for this purpose.

I give you an idea about what is needed inside britney, and what we are
currently performing with an ad-hoc python extension:

# python pseudo-code
from britney import buildSystem

# we build a virtual i386 system with a list of packages from
# a standard ad-hoc python dict
packages = {'foo': [...], 'bar': [...]}
system_i386 = buildSystem("i386", packages)

# we check the installability for foo and bar
print system_i386.is_installable('foo')
print system_i386.is_installable('bar')

# we remove a binary package
system_i386.remove_binary('foo')
new_pkg = [...]
system_i386.add_binary('baz', new_pkg)


Is it possible, in your opinion, to directly use dpkg from python for this
purpose? Any hints about where to start looking at the code?

(please Cc me on replies, I'm not subscribed to this list)

Thanks in advance,

--
Fabio Tranchitella <kobold@debian.org> .'`.
Proud Debian GNU/Linux developer, admin and user. : :' :
`. `'`
http://people.debian.org/~kobold/ `-
__________________________________________________ ___________________
1024D/7F961564, fpr 5465 6E69 E559 6466 BF3D 9F01 2BF8 EE2B 7F96 1564

Hi Fabio,

On Fri, 02 May 2008, Fabio Tranchitella wrote:
> I give you an idea about what is needed inside britney, and what we are
> currently performing with an ad-hoc python extension:
>
> # python pseudo-code
> from britney import buildSystem
>
> # we build a virtual i386 system with a list of packages from
> # a standard ad-hoc python dict
> packages = {'foo': [...], 'bar': [...]}
> system_i386 = buildSystem("i386", packages)
>
> # we check the installability for foo and bar
> print system_i386.is_installable('foo')
> print system_i386.is_installable('bar')
>
> # we remove a binary package
> system_i386.remove_binary('foo')
> new_pkg = [...]
> system_i386.add_binary('baz', new_pkg)
>
> Is it possible, in your opinion, to directly use dpkg from python for this
> purpose? Any hints about where to start looking at the code?

Well, this code excerpt doesn't tell us at all how dpkg is currently used
in britney. Can you point us to the relevant code ?

In the end, I suppose that the right path is to export whatever is needed
in libdpkg and make that library a shared one instead of a statically
linked one. After that you can of course build a python wrapper module.

But you will have to talk to Guillem for more specific details.

Cheers,
--
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Hello Raphael,

thanks for your answer.

* 2008-05-05 20:26, Raphael Hertzog wrote:
> Well, this code excerpt doesn't tell us at all how dpkg is currently used
> in britney. Can you point us to the relevant code ?

The very only feature of dpkg needed by britney is checking if a given
package is installable or not within a given set of packages. What britney
should be able to do is to build a system of binary packages and check the
installability of (some of) them evaluating dependencies, conflicts and so
on.

> In the end, I suppose that the right path is to export whatever is needed
> in libdpkg and make that library a shared one instead of a statically
> linked one. After that you can of course build a python wrapper module.

That's the my idea, but for that I need some help to figure out at least
where I should look for. :-)

> But you will have to talk to Guillem for more specific details.

What is the best way to reach him, other than this mailing list?

Thanks for your support,

--
Fabio Tranchitella http://www.kobold.it
Free Software Developer and Consultant http://www.tranchitella.it
__________________________________________________ ___________________
1024D/7F961564, fpr 5465 6E69 E559 6466 BF3D 9F01 2BF8 EE2B 7F96 1564


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

On Mon, 05 May 2008, Fabio Tranchitella wrote:
> * 2008-05-05 20:26, Raphael Hertzog wrote:
> > Well, this code excerpt doesn't tell us at all how dpkg is currently used
> > in britney. Can you point us to the relevant code ?
>
> The very only feature of dpkg needed by britney is checking if a given
> package is installable or not within a given set of packages. What britney
> should be able to do is to build a system of binary packages and check the
> installability of (some of) them evaluating dependencies, conflicts and so
> on.

I understood this, but since I'm not familiar with the C code of dpkg this
doesn't map nicely to function names in my head... that's why looking at
the actual dpkg code used by britney would be helpful to identify your
needs.

> > In the end, I suppose that the right path is to export whatever is needed
> > in libdpkg and make that library a shared one instead of a statically
> > linked one. After that you can of course build a python wrapper module.
>
> That's the my idea, but for that I need some help to figure out at least
> where I should look for. :-)

In the "lib" subdirectory of the dpkg source archive? :-)

> > But you will have to talk to Guillem for more specific details.
>
> What is the best way to reach him, other than this mailing list?

"braindmg" or "guillem" on IRC.

Cheers,
--
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Hallo Fabio,

Fabio Tranchitella <kobold@kobold.it> wrote:
> * 2008-05-05 20:26, Raphael Hertzog wrote:
>> Well, this code excerpt doesn't tell us at all how dpkg is currently used
>> in britney. Can you point us to the relevant code ?
>
> The very only feature of dpkg needed by britney is checking if a given
> package is installable or not within a given set of packages. What britney
> should be able to do is to build a system of binary packages and check the
> installability of (some of) them evaluating dependencies, conflicts and so
> on.

Are you looking for something like

dpkg --simulate --admindir=/my_own_var_lib_dpkg --install $package

I don't really understand what you want to do.

Regards, Jörg.
--
MCSE = Minesweeper Consultant & Solitaire Expert


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Hi,

On Fri, 2008-05-02 at 16:54:47 +0200, Fabio Tranchitella wrote:
> as you probably already know, britney (the testing migration script) is
> using a local customized dpkg source to test the installability of a
> package while updating the testing distribution.

Just for reference, britney sources seem to be at:

<http://git.debian.org/?p=tools-release/britney.git>
<http://release.debian.org/britney/code/update_out/>

the "dpkg" files there do not seem to be really derived from dpkg
sources, they seem to contain a specialized reimplementation.

> This is not really easy to manage, and in fact the code is quite complex to
> maintain and debug. I'm sure that it would be possible to use dpkg
> directly, and this would help a lot the release team maintaining britney
> without taking care of the details for the installability check. The
> problem is that I don't know at all the dpkg internals and I have no idea
> about the parts of the dpkg source code which should be exposed to britney
> for this purpose.

> Is it possible, in your opinion, to directly use dpkg from python for this
> purpose? Any hints about where to start looking at the code?

Yes, I guess it would be possible, but what should be considered is if
that would be desirable. britney only cares about a subset of the
package metadata and does not need to keep the rest in memmory. It
also has its optimized memory pool handling. Being it a long lived
process with a huge amount of data to process and keep, any additional
unneeded operation or data seem like a big problem to me.

Also as an easy optimization target, you could check how fast (if
any) is apt's compare version function vs dpkg's one, and replace that
call from dpkg-lib.cpp.

regards,
guillem


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org