Re: MBF: embedded copies of Python modules
anatoly techtonik <techtonik@gmail.com> writes:
> 2009/11/8 Jakub Wilk <ubanus@users.sf.net>:
>> I am going to file a few dozens of bugs against packages that are
>> embedding copies of Python modules; more specifically:
> Do you mean that all these packages need to stick to the stable
> standard version of some Module available in Debian?
Except in unusual situations, yes.
> I personally think that fit is a bad idea, because by upgrading such
> Module it is possible to break Python Application that require older
> version of the Module for its equivalent stable version.
That usually indicates bad API design by the module author. There's often
a way to work around that, using the standard API change techniques that
apply across programming languages.
Having multiple copies of code is a nightmare for security support, since
if a security bug is uncovered in that code, it's almost impossible to
track down all the applications that need to be updated. It's also in
general good for all the applications using the shared code, since this
way they benefit from bug fixes from other applications. The standard
advantage of open source.
> How does Debian Policy 4.13 (Convenience copies of code) deal in this
> case?
It says you shouldn't embed copies of code. In other words, it says don't
do this.
> Is it possible for Python Applications to maintain their own set of
> "stable" modules independently? For example by building virtualenv upon
> installation and filling missing dependencies online through custom
> mirror of PyPi packages with added Debian specifics?
Down this path lies the worst problems with Ruby and Java applications.
It's one of the reasons why they're so horrible to try to support. It's a
bad idea, however tempting it may appear as a matter of expedience.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: