[openstack-dev] [DevStack] Python dependencies: PyPI vs distro packages

Joshua Harlow harlowja at yahoo-inc.com
Wed Aug 7 17:43:19 UTC 2013

Interesting, I should look into conary.

I was hoping that DNF (the yum rewrite) would be a little better at this
stage, but it still seems a ways off.

And I'm also not sure if DNF is attempting to even address this kind of
stuff, although I don't quite see how RH if they plan on selling RDO can
avoid the rollback scenario (likely using yum to do this). Maybe with the
investment in triple-o that will be the solution. I know at y! we've
struggled with this ourselves (and right now have some thing like a huge
rpm 'manifest' that we can attempt to rollback with). Its not an easy
problem, but I would hope the distros would solve it (especially if they
believe package management is the way forward, if not then venv and such
isolated installs should be the way forward).

On 8/7/13 10:09 AM, "Jeremy Stanley" <fungi at yuggoth.org> wrote:

>On 2013-08-07 15:53:54 +0000 (+0000), Joshua Harlow wrote:
>> I agree triple-o will help a lot here although I would disagree
>> that package rollback is an illusion. I would call it more of a
>> hard problem instead since nothing is really impossible :)
>SCO OpenServer (shudder) for all its issues, actually didn't do a
>half bad job of it. The Conary package manager takes a similar
>approach, as have others. RPM/DEB style packages and the
>corresponding management tools inherit from their parent operating
>system designs a focus on efficiencies like static footprint and
>memory consumption which make this a much harder problem (shared
>libraries, shared interpreters, et cetera). The trend toward every
>application in its own independent context does make the downgrade
>problem much more tractable, though you still have issues like
>un-transforming your data while still capturing any changes which
>have been applied to it since migration.
>Jeremy Stanley
>OpenStack-dev mailing list
>OpenStack-dev at lists.openstack.org

More information about the OpenStack-dev mailing list