[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: python conflict question
"J. Lewis Muir" <jlmuir%imca-cat.org@localhost> writes:
> It's also awkward from a user perspective when installing binary
> packages: you can't do "pkgin install certbot"; instead you have to do
> "pkgin install py38-certbot" (replacing 38 with whatever version of
> Python you want it to use that's available as a binary package). That's
> just weird from a user perspective: I just want the Certbot program, I
> don't care what version of Python it uses.
> Certbot is just an example. IMO, it would be good for any program
> like this to have a meta package like Mercurial does if it must have
> the short language prefix name. I understand the rationale that
> devel/py-mercurial has other packages that use it. That's fine.
> And it makes it available at the name you'd expect by having the
> devel/mercurial meta package. It's just that for any program like this,
> I think the user is expecting to find it at a name that does not begin
> with the short language prefix.
You are basically right about this being awkward. Keep in mind that the
root cause is poor inter-version compatibilty in Python; if we could
just use any python version for any program, we would probably only have
one (like perl).
Given that we are talking about mitigating awkwardness, it's a
non-obvious call what the approach is for the least total problems.
Adding another 100 metapackages foo to wrap py-foo seems like it might
be more trouble than it is worth. I find that that I have to "ls -l
*/*foo*" to find the foo package anyway, so the py- prefix doesn't
bother me much.
Perhaps if pkgin said when "pkgin in certbot" is invoked:
There is no "certbot"; did you mean "py-certbot"?
that would help a lot.
Main Index |
Thread Index |