I broke Yum (by messing with Python libs)

[Martin Cigorraga]

Hi all,

After upgrading some python packages via pip I found I left Yum in a
non-working state:

There was a problem importing one of the Python modules
required to run yum. The error leading to this problem was:

pycurl: libcurl link-time ssl backend (nss) is different from
compile-time ssl backend (none/other)

Please install a package which provides this module, or
verify that the module is installed correctly.

It's possible that the above module doesn't match the
current version of Python, which is:
2.7.8 (default, Nov 10 2014, 08:19:18)
[GCC 4.9.2 20141101 (Red Hat 4.9.2-1)]

//

Now, what I did to fix the mess was:
1. Download python-pycurl-7.19.3.1-5.fc21.x86_64.rpm;
2. rpm --nodeps -e python-curl
3. rpm -ivh python-pycurl-7.19.3.1-5.fc21.x86_64.rpm.

So far so good, Yum isn't complaining anymore about the library version
mismatch; however I would like to know if I proceeded right or if there's
still any missing step(s) I should follow to ensure a proper system
integrity.

Thanks and have a nice Sunday!
(At least what's left of it :)
-Martin

[Sylvia Sánchez]

If you use yum to install something, does it works?
BTW, what Fedora version are you using?

Cheers!

[Martin Cigorraga]

Hey,

so far yum seems to work okay, I'm on F21.
-M.

On Sun, Mar 22, 2015 at 9:40 PM, Sylvia Sánchez  wrote:
> If you use yum to install something, does it works?
> BTW, what Fedora version are you using?
> Cheers!
>
> users mailing list
> [e-mail]
> To unsubscribe or change subscription options:
> https://admin.fedoraproject.org/mailman/listinfo/users
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
> Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
> Have a question? Ask away: http://ask.fedoraproject.org

[Sylvia Sánchez]

Then there's no need of further work.
Anyway, I think yum is going to be dropped. I don't remember right now
the name of its substitute tough.
Sorry, my memory is terrible.

Cheers!

[EGO-II.1]

On 03/22/2015 09:37 PM, Sylvia Sánchez wrote:
> Then there's no need of further work.
> Anyway, I think yum is going to be dropped. I don't remember right now
> the name of its substitute tough.
> Sorry, my memory is terrible.
>
> Cheers!

I didn't know yum was "breakable"! LoL! I have yet to mess with anything 
regarding libraries and the like in Fedora, I've been content to just 
let it go its own way and if I'm tempted to fiddle-faddle with anything 
I usually do it on a test machine. I think the replacement for yum is 
called "dnf"?....(Dandified Yum...or so they say!) I don't know why they 
feel they need to replace yum, it's been stable and has worked great 
since I've been using Fedora...(from around 13 / 14...) I guess progress 
dictates that all things must change huh?.......just my two cents...

EGO II

[Sylvia Sánchez]

Yeah, that's it, dnf.  And I don't know why they change it neither.
I like yum so far, it's simple, clean and stable. But well, so be it.

Cheers!
:-)

[Cameron Simpson]

On 22Mar2015 17:10, Martin Cigorraga  wrote:
> After upgrading some python packages via pip I found I left Yum in a
> non-working state: [...]

I have found it is quite important to completely separate "supplier" package 
updates (i.e. yum supplied) and user driven package updates and/or additions 
(i.e. pip). This holds with Perl, Python, etc.

In the case of python I strongly advocate making a virtualenv (easier than 
you'd think) and run pip within that. This has the advantage of:

- keeping extra packages completely away from the system packages

- lets you use multiple versions of Python as needed (the system Python, other Pythons installed in /usr/local or /opt etc)

- with the right permissions, lets you create and maintain the virtualenv area as yourself; I keep a current python2 and python3 virtualenv in my homedir routinely

Do not touch the system packages!!!

[...]
> Now, what I did to fix the mess was:
> Download python-pycurl-7.19.3.1-5.fc21.x86_64.rpm;
> rpm --nodeps -e python-curl
> rpm -ivh python-pycurl-7.19.3.1-5.fc21.x86_64.rpm.
>
> So far so good, Yum isn't complaining anymore about the library version
> mismatch; however I would like to know if I proceeded right or if there's
> still any missing step(s) I should follow to ensure a proper system
> integrity.

Just this: let yum maintain the system python packages and use a virtualenv for 
your extras. NB: you can set up the virtualenv to live off the system python 
(or whichever) as a basis, which means that anything you _do_ install with yum 
is then available for free in the virtualenv. Or you can make it standalone and 
use the virtualenv pip for aal its extras.

Cheers,
Cameron Simpson

[Michael Schwendt]

On Sun, 22 Mar 2015 23:03:21 -0400, Eddie G. O'Connor Jr. wrote:
> called "dnf"?....(Dandified Yum...or so they say!) I don't know why they 
> feel they need to replace yum, it's been stable and has worked great 
> since I've been using Fedora...(from around 13 / 14...) I guess progress 
> dictates that all things must change huh?.......just my two cents...

"Stable"? Maybe for basic operation. There are tons of bugs, though,
and these are just the Fedora bugzilla tickets:

http://bugz.fedoraproject.org/yum

Also, sometimes "stable" just means that development of the software is
stuck, and fixing bugs or adding features has become too complicated or
too dangerous. Eventually the developers find that they would like to
rewrite large portions of the code or even everything.

Meanwhile, there have been new backend libraries, such as package
dependency resolvers that are more powerful (with regard to features
in RPM that Fedora would like to use), more flexible, faster, simply
considered superior by the developers who would like to use them
instead of fighting with the aging code of Yum.

Whether the new software will become better cannot be said yet.
There are lots of issues already: http://bugz.fedoraproject.org/dnf

[Martin Cigorraga]

Hello Cameron,

Exactly! I absolutely agree with you.
In the past I never experienced such issues as the package manager my
previous distribution uses is written in C - without any external
dependencies other than its own libraries.
Thank you very much for your suggestions, I will implement my own Python
environments the way you explained as it seems the only sane way to work
with them.

B.R.,
-Martín