Mailinglist Archive: opensuse-packaging (267 mails)

[Claudio Freire <klaussfreire@xxxxxxxxx>]

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)

> > 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.
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.

> 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.
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse-packaging+owner@xxxxxxxxxxxx