unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Leo Famulari <leo@famulari.name>
To: Jan Nieuwenhuizen <janneke@gnu.org>
Cc: guix-devel@gnu.org, rennes@openmailbox.org, 宋文武 <iyzsong@gmail.com>
Subject: Re: [PATCH 2/2] gnu: Add gnome-tweak-tool.
Date: Sun, 24 Apr 2016 14:50:20 -0400	[thread overview]
Message-ID: <20160424185020.GA7737@jasmine> (raw)
In-Reply-To: <87wpnnz22g.fsf@drakenvlieg.flower>

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 ;)

  reply	other threads:[~2016-04-24 18:50 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-03 11:07 [PATCH 2/2] gnu: Add gnome-tweak-tool Jan Nieuwenhuizen
2016-04-03 16:41 ` Jan Nieuwenhuizen
2016-04-11 23:35 ` Leo Famulari
2016-04-13 18:02   ` Jan Nieuwenhuizen
2016-04-16  1:35     ` Leo Famulari
2016-04-17 17:22       ` Jan Nieuwenhuizen
2016-04-17 18:33         ` rennes
2016-04-17 18:44         ` Leo Famulari
2016-04-24 11:19           ` Jan Nieuwenhuizen
2016-04-24 18:50             ` Leo Famulari [this message]
2016-04-27 19:05               ` Jan Nieuwenhuizen
2016-05-01 21:36                 ` rennes
2016-05-02 22:04                 ` Leo Famulari
2016-05-02 22:38                   ` Jan Nieuwenhuizen
2016-05-03  2:19                     ` Leo Famulari
2016-05-15 17:31                       ` Leo Famulari
     [not found] <mailman.877.1460442807.7476.guix-devel@gnu.org>
2016-04-12 13:16 ` rennes

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160424185020.GA7737@jasmine \
    --to=leo@famulari.name \
    --cc=guix-devel@gnu.org \
    --cc=iyzsong@gmail.com \
    --cc=janneke@gnu.org \
    --cc=rennes@openmailbox.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).