[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH 2/2] gnu: Add gnome-tweak-tool.
From: |
Leo Famulari |
Subject: |
Re: [PATCH 2/2] gnu: Add gnome-tweak-tool. |
Date: |
Sun, 24 Apr 2016 14:50:20 -0400 |
User-agent: |
Mutt/1.5.24 (2015-08-30) |
On Sun, Apr 24, 2016 at 01:19:35PM +0200, Jan Nieuwenhuizen wrote:
> Leo Famulari writes:
> > I think we need to wrap gnome-tweak-tool's executable, which the
> > python-build-system normally does automatically. AIUI, that's why all of
> > the python-build-system packages don't require Python itself to be
> > propagated.
>
> Sorry, I still don't understand. Can you explain why you want to remove
> python2 from the propagated inputs?
Propagated-inputs are silently installed into the user's profile
alongside the package that propagates them. In this case, installing
gnome-tweak-tool would also install python2 into the user's profile.
Propagation becomes attractive when the software provided by a package
does not have a good mechanism for finding its dependencies. For
example, some software may *only* be able to find a dependency by
looking on PATH. Gnome-tweak-tool, as far as we know, has this
limitation for python2.
The problem with propagating inputs is that only one version of a given
package may be installed into a user's profile. This is in contrast to
"regular" inputs, which are not installed into a user's profile. Indeed,
every package that you install into your profile could refer to a
different version of, say, libfoo, by linking directly to the various
libfoos' directories in the store.
So, letting gnome-tweak-tool propagate python2 would prevent a Python
programmer from choosing which version of python2 they want in their
profile; they'd be forced to choose between gnome-tweak-tool or their
desired python2.
Does that make sense?
> And also...say we wrap gnome-tweak-tool. If we remove python2 from the
> propagated inputs, AIUI it python2 will not be installed and it even
> could just be that python2 is not downloaded at all under /gnu.
>
> How is wrapping gnome-tweak-tool going to help if we fail to make sure
> that python2 is present? Sorry for my ignorance.
An alternative to propagated-inputs is to use a wrapper. Actually, all
of our packages using the python-build-system are wrapped automatically
[0]. The wrapper makes the dependent packages available in the run-time
environment without polluting the user's profile, while introducing a
reference to the dependencies into the store directory, which makes sure
that the garbage collector works correctly.
Does that make sense?
Hopefully, I've got that all right — I'll be happy if somebody clarifies
or corrects me!
[0] If gnome-tweak-tool did not break convention by using the Autotools
to build Python software, this discussion would not be happening ;)
- [PATCH 2/2] gnu: Add gnome-tweak-tool., Jan Nieuwenhuizen, 2016/04/03
- Re: [PATCH 2/2] gnu: Add gnome-tweak-tool., Jan Nieuwenhuizen, 2016/04/03
- Re: [PATCH 2/2] gnu: Add gnome-tweak-tool., Leo Famulari, 2016/04/11
- Re: [PATCH 2/2] gnu: Add gnome-tweak-tool., Jan Nieuwenhuizen, 2016/04/13
- Re: [PATCH 2/2] gnu: Add gnome-tweak-tool., Leo Famulari, 2016/04/15
- Re: [PATCH 2/2] gnu: Add gnome-tweak-tool., Jan Nieuwenhuizen, 2016/04/17
- Re: [PATCH 2/2] gnu: Add gnome-tweak-tool., rennes, 2016/04/17
- Re: [PATCH 2/2] gnu: Add gnome-tweak-tool., Leo Famulari, 2016/04/17
- Re: [PATCH 2/2] gnu: Add gnome-tweak-tool., Jan Nieuwenhuizen, 2016/04/24
- Re: [PATCH 2/2] gnu: Add gnome-tweak-tool.,
Leo Famulari <=
- Re: [PATCH 2/2] gnu: Add gnome-tweak-tool., Jan Nieuwenhuizen, 2016/04/27