Subject: python-apt: apt_pkg.init_config() should apt_pkg.config.clean()
Date: Fri, 05 Sep 2014 09:56:26 +0200
Package: python-apt
Version: 0.9.3.9
Severity: normal
I have had symptoms very similar to http://bugs.debian.org/728274 but in
a different context.
I want to use apt_pkg directly and want to call apt_pkg.init() after
having set APT_CONFIG to point to my custom configuration. Unfortunately
my code also "import apt" (because it needs apt.progress.base.AcquireProgress)
and that import unhelpfully triggers apt_pkg.init().
Even though I'm calling that a second time, the configuration is not
cleared and while the entries I have defined are overriden, the global
entries (such as APT::Target-Release) are there to interfere with
my logic.
Thus I believe that a call to apt_pkg.init_config() should really clear
the apt_pkg.config object first. That's what I did in my code:
http://anonscm.debian.org/cgit/qa/distro-tracker.git/commit/?id=e34d8aaaca11b0706ffa9a773f65442c9c24c987
+ # Clean up the configuration we might have read during "import apt"
+ for root_key in apt_pkg.config.list():
+ apt_pkg.config.clear(root_key)
+ # Load the proper configuration
apt_pkg.init()
Furthermore it would be nice if the configuration was loaded in a lazy
way in all the apt.* modules. That would probably solve #728274.
-- System Information:
Debian Release: jessie/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.14-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages python-apt depends on:
ii libapt-inst1.5 1.0.7
ii libapt-pkg4.12 1.0.7
ii libc6 2.19-10
ii libgcc1 1:4.9.1-12
ii libstdc++6 4.9.1-12
ii python 2.7.8-1
ii python-apt-common 0.9.3.9
Versions of packages python-apt recommends:
ii iso-codes 3.56-1
ii lsb-release 4.1+Debian13
ii xz-utils 5.1.1alpha+20120614-2
Versions of packages python-apt suggests:
pn python-apt-dbg <none>
ii python-apt-doc 0.9.3.9
ii python-gtk2 2.24.0-4
ii python-vte 1:0.28.2-5
-- no debconf information
Acknowledgement sent
to Julian Andres Klode <[email protected]>:
Extra info received and forwarded to list. Copy sent to APT Development Team <[email protected]>.
(Fri, 05 Sep 2014 08:24:09 GMT) (full text, mbox, link).
Subject: Re: Bug#760549: python-apt: apt_pkg.init_config() should
apt_pkg.config.clean()
Date: Fri, 5 Sep 2014 10:21:58 +0200
Control: tag -1 wontfix
On Fri, Sep 05, 2014 at 09:56:26AM +0200, Raphaël Hertzog wrote:
> Package: python-apt
> Version: 0.9.3.9
> Severity: normal
>
> I have had symptoms very similar to http://bugs.debian.org/728274 but in
> a different context.
>
> I want to use apt_pkg directly and want to call apt_pkg.init() after
> having set APT_CONFIG to point to my custom configuration. Unfortunately
> my code also "import apt" (because it needs apt.progress.base.AcquireProgress)
> and that import unhelpfully triggers apt_pkg.init().
>
> Even though I'm calling that a second time, the configuration is not
> cleared and while the entries I have defined are overriden, the global
> entries (such as APT::Target-Release) are there to interfere with
> my logic.
>
> Thus I believe that a call to apt_pkg.init_config() should really clear
> the apt_pkg.config object first. That's what I did in my code:
That would break other code unfortunately, especially code using different
root directories, as init_config() looks at Dir::Etc::main and stuff to
find the configuration files to look.
If we cleared in init_config(), you could not specify a different root
directory or other settings for another root directory you are working
with.
We could whitelist some stuff we don't want to clear, but that would be a bit
inconsistent and we'd probably get the list wrong anyway.
> Furthermore it would be nice if the configuration was loaded in a lazy
> way in all the apt.* modules. That would probably solve #728274.
It would not, AFAICT. The thing with #728274 is that is a use case that
directly conflicts with another use case. One group of users like in the
bug report want to specify configuration files in the chroot, and others
are setting them outside the chroot (especially APT::Architecture for
foreign chroots).
Both cannot work together. And because the latter was existing behaviour,
it had to be reverted.
--
Julian Andres Klode - Debian Developer, Ubuntu Member
See http://wiki.debian.org/JulianAndresKlode and http://jak-linux.org/.
Be friendly, do not top-post, and follow RFC 1855 "Netiquette".
- If you don't I might ignore you.
Acknowledgement sent
to Julian Andres Klode <[email protected]>:
Extra info received and forwarded to list. Copy sent to APT Development Team <[email protected]>.
(Fri, 05 Sep 2014 08:33:04 GMT) (full text, mbox, link).
Subject: Re: Bug#760549: python-apt: apt_pkg.init_config() should apt_pkg.config.clean()
Date: Fri, 5 Sep 2014 10:31:13 +0200
On Fri, Sep 5, 2014 at 10:21 AM, Julian Andres Klode <[email protected]> wrote:
> On Fri, Sep 05, 2014 at 09:56:26AM +0200, Raphaël Hertzog wrote:
>> Furthermore it would be nice if the configuration was loaded in a lazy
>> way in all the apt.* modules. That would probably solve #728274.
>
> It would not, AFAICT. The thing with #728274 is that is a use case that
> directly conflicts with another use case. One group of users like in the
> bug report want to specify configuration files in the chroot, and others
> are setting them outside the chroot (especially APT::Architecture for
> foreign chroots).
Sorry, yes it actually would solve it in case you only create a single
Cache(). Unfortunately, our configuration is a global thing, and thus
the entries from the different root directory would remain even after
the cache was closed; for example, when creating a new one.
It might make sense to provide the ability to switch apt_pkg.config
between different Configuration instances (setting _config on the C++
level), but I'm not sure if that would provide a consistent behaviour.
In short, global state sucks a lot, and there's not much we can do to fix it.
--
Julian Andres Klode - Debian Developer, Ubuntu Member
See http://wiki.debian.org/JulianAndresKlode and http://jak-linux.org/.
Acknowledgement sent
to Raphael Hertzog <[email protected]>:
Extra info received and forwarded to list. Copy sent to APT Development Team <[email protected]>.
(Fri, 05 Sep 2014 09:36:04 GMT) (full text, mbox, link).
Subject: Re: Bug#760549: python-apt: apt_pkg.init_config() should
apt_pkg.config.clean()
Date: Fri, 5 Sep 2014 11:33:12 +0200
On Fri, 05 Sep 2014, Julian Andres Klode wrote:
> On Fri, Sep 5, 2014 at 10:21 AM, Julian Andres Klode <[email protected]> wrote:
> > On Fri, Sep 05, 2014 at 09:56:26AM +0200, Raphaël Hertzog wrote:
> >> Furthermore it would be nice if the configuration was loaded in a lazy
> >> way in all the apt.* modules. That would probably solve #728274.
> >
> > It would not, AFAICT. The thing with #728274 is that is a use case that
> > directly conflicts with another use case. One group of users like in the
> > bug report want to specify configuration files in the chroot, and others
> > are setting them outside the chroot (especially APT::Architecture for
> > foreign chroots).
>
> Sorry, yes it actually would solve it in case you only create a single
> Cache(). Unfortunately, our configuration is a global thing, and thus
> the entries from the different root directory would remain even after
> the cache was closed; for example, when creating a new one.
>
> It might make sense to provide the ability to switch apt_pkg.config
> between different Configuration instances (setting _config on the C++
> level), but I'm not sure if that would provide a consistent behaviour.
>
> In short, global state sucks a lot, and there's not much we can do to fix it.
Well, you could at least avoid to initialize it before the user had a
chance to initialize it the way he want...
Hence the suggestion of lazy loading. It would not fix the case where
people want to use multiple configurations, but it would fix my use case
where I want a single configuration that is not polluted by the
system-wide configuration.
Cheers,
--
Raphaël Hertzog ◈ Debian Developer
Discover the Debian Administrator's Handbook:
→ http://debian-handbook.info/get/
Debbugs is free software and licensed under the terms of the GNU General
Public License version 2. The current version can be obtained
from https://bugs.debian.org/debbugs-source/.