unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: taylanbayirli@gmail.com (Taylan Ulrich Bayırlı/Kammer)
To: "Ludovic Courtès" <ludo@gnu.org>
Cc: guix-devel@gnu.org
Subject: Re: [PATCH] gnu: Add Nmap.
Date: Mon, 24 Nov 2014 00:51:06 +0100	[thread overview]
Message-ID: <87k32l8oid.fsf@taylan.uni.cx> (raw)
In-Reply-To: <87mw7h4pqf.fsf@gnu.org> ("Ludovic \=\?utf-8\?Q\?Court\=C3\=A8s\=22'\?\= \=\?utf-8\?Q\?s\?\= message of "Sun, 23 Nov 2014 21:38:16 +0100")

ludo@gnu.org (Ludovic Courtès) writes:

> This is normally dealt with by using multiple outputs (info "(guix)
> Packages with Multiple Outputs").  An example of that is Git: the Tcl
> GUIs are moved to a separate output, and so is git-svn support, such
> that the main output does not depend on Tcl, libx11, Subversion, etc.

OK, will have a go at this.

It seems Zenmap doesn't need X11/GTK libraries (rather headers) at build
time because it only uses a Python GTK module.  This raises two general
questions for me:

1) Is it OK if users have to install additional packages for a given
   component of a package to work, or should all dependencies, even if
   purely run-time, be inputs?

2) If purely-run-time dependencies are inputs, won't that trigger
   unnecessary rebuilds of the package when a run-time dependency is
   updated?

(In this special case only question 2 applies, because the whole of
Zenmap is useless without GTK, not just a component of it.)

After some pondering, I would say:

1) There should be a way to run-time-depend on another package without
   it being a build input at all.  (The installation of these needn't be
   forced on the user, though in some cases like Zenmap it's senseless
   not to do so; we could have "dependencies" and "recommendations" and
   possibly more, like in Debian.)

2) When interface files of a dylib are needed during compilation of a
   static lang (e.g. C headers), a special for-building package should
   be used as input, thus the actual dylib can be updated without
   causing rebuilds.  (Until ABI compatibility breaks I guess.)

3) Similarly, when a program is needed purely at build-time, like Bash
   or SCons, a special for-building package should be used as input,
   thus the actual program can be updated without causing rebuilds.
   (The for-building package would be updated only when doing so will
   improve the builds, like when a newer GCC version optimizes better.)

4) The for-building packages in #3 should obviously not be installed on
   the user's machine (unless they build locally instead of using binary
   substitutes), meaning "build inputs" and "run-time dependencies" are
   fully orthogonal.

In the Nix manual I see the following, which possibly fixes #4 without
needing to separate build inputs from run-time dependencies in recipes:

"Runtime dependencies are found by scanning binaries for the hash parts
of Nix store paths (such as r8vvq9kq…). This sounds risky, but it works
extremely well."

Perhaps we already do that?  But otherwise, it seems like we could save
gigawatts of electricity over time with #1-3.  Please tell me if I'm
missing something obvious. :-)

Taylan

  reply	other threads:[~2014-11-23 23:51 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-22 22:05 [PATCH] gnu: Add Nmap "Taylan Ulrich Bayırlı/Kammer"
2014-11-23  9:02 ` Andreas Enge
2014-11-23 11:54   ` Taylan Ulrich Bayırlı/Kammer
2014-11-23 20:38     ` Ludovic Courtès
2014-11-23 23:51       ` Taylan Ulrich Bayırlı/Kammer [this message]
2014-11-24 14:22         ` Ludovic Courtès
2014-11-24 20:52           ` Taylan Ulrich Bayırlı/Kammer
2014-11-25 21:09             ` Ludovic Courtès
2014-11-25 23:25               ` Taylan Ulrich Bayırlı/Kammer
2014-11-26  2:01                 ` Eric Bavier

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=87k32l8oid.fsf@taylan.uni.cx \
    --to=taylanbayirli@gmail.com \
    --cc=guix-devel@gnu.org \
    --cc=ludo@gnu.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).