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.

Control: tag -1 wontfix

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.

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.

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,