Mailinglist Archive: opensuse-packaging (267 mails)

[todd rme <toddrme2178@xxxxxxxxx>]

On Tue, Dec 6, 2011 at 3:25 PM, Claudio Freire <klaussfreire@xxxxxxxxx> wrote:
> On Tue, Dec 6, 2011 at 6:03 AM, todd rme <toddrme2178@xxxxxxxxx> wrote:
> > On Tue, Dec 6, 2011 at 2:06 AM, Claudio Freire <klaussfreire@xxxxxxxxx> 
> > wrote:
> > That is simply not true.  A great many "libs" also install files in
> > /usr/bin.
>
> They shouldn't...
>
> > > I believe the number of packages won't be that huge.
> >
> > Let me give some more concrete numbers.  I opened the first 20 rows of
> > python-___ packages in devel:languages:python.  That is about 170
> > packages, and I exclude the about 45 packages that use files lists so
> > I can't tell the contents.  That leaves about 125 packages.  Of those,
> > about 50 have this issue, or about 40%.  If that is representative,
> > that is over 370 packages just amongst the python-___ packages in
> > devel:languages:python alone.
>
> That *is* a problem.
> Python libs shouldn't be installing new binaries... what are they installing?
> Maybe it's an error. Maybe I just misjudged the number of libs
> performing dual functions (lib + app)

They aren't usually binaries, they are usually scripts.  They appear
to mostly be commandline (i.e. bash shell) wrappers around one or more
python functions, letting you access one or more of the library's
basic capabilities from within bash or other similar shell instead of
needing to open a python shell.  For instance numpy provides a
fortran-to-python converter called f2py, cxfreeze has a script to
convert a script to a stand-alone executable, pygment (a source code
highlighting function) provides a script to highlight source code and
store the highlights to a file, python-googletranslate of course
provides a translator script, and so on.  For things like pygment and
googletranslate it doesn't really matter what is used, but for things
like f2py and cxfreeze the version of python the script calls can have
a major or even critical impact.

> > > Notice that you could easily build a macro for that rename, since it
> > > means renaming all the binaries installed in %{_bindir}. So the change
> > > isn't that "personalized" for each package. And if you decide to use a
> > > subdirectory within bindir that's even easier, since a macro can
> > > create the symlinks with one bash command.
> > >
> > > So it *can* be made to scale. It only requires a bit of thought and 
> > > prevision.
> >
> > Even with that, it is still not as straightforward as the approach I
> > propose, since it still requires additional lines in the spec file
> > beyond what would be required just to add python3 support to the
> > package.  Besides scalability, I listed what I consider to be a number
> > of other advantages to the approach I support.
> >
> > As for adding them to a subdirectory of bindir, that was another
> > approach I suggested, but once again I only see disadvantages to this
> > approach.
> >
> > What reasons do you have for choosing the approach you chose?
>
> Only that I do not like the idea of fiddling with standard python paths.
> It will require a lot of care and testing to make things like
> setuptools, easy install and in general manually-installed packages to
> not break.

The problem is we either have to fiddle with paths, or fiddle with
names.  At least with paths, distutils (and presumably python) is
aware of the change.  And as you said, it can still be symlinked to
the proper place.

> Furthermore, when you suffix the binary with the python version, it is
> rather straightforward to choose a python version:
>
> $ easy_install2
> $ easy_install3
>
> Or, the more standard
>
> $ easy_install-2.6
> $ easy_install-3.1
>
> From the POV of a user, it is a lot better (a lot more explicit and
> clean) than fiddling with the PATH.

That is true, although on the other hand it leads to ambiguity about
whether the number is the python version or the version of the script.

> > Of course if there is a reason why this approach would be preferable I
> > would support it.  I am trying to figure out the best approach, by
> > looking at the advantages and disadvantages to each approach.  I don't
> > see any advantages to this approach, but I very well may just not have
> > thought of them.
>
> With your numbers about the number of lib packages "misbehaving", your
> option 4 is starting to sound better.
> I still maintain that it's a lot clearer and cleaner for a user to
> type "easy_install3" than to fiddle with the PATH in order to get
> easy_install for python3..
>
> So we're down to what's better for a user vs. what's better for the packager.

It also depends on how likely users are to use the scripts, and how
likely they are to care which one they use.

-Todd
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse-packaging+owner@xxxxxxxxxxxx