unofficial mirror of guile-devel@gnu.org 
 help / color / mirror / Atom feed
From: Mark H Weaver <mhw@netris.org>
To: "Jose A. Ortega Ruiz" <jao@gnu.org>
Cc: guile-devel@gnu.org
Subject: Re: summer of code ideas
Date: Mon, 07 Mar 2011 20:10:01 -0500	[thread overview]
Message-ID: <87oc5mxvrq.fsf@netris.org> (raw)
In-Reply-To: <87vczur5cf.fsf@gnu.org> (Jose A. Ortega Ruiz's message of "Mon,  07 Mar 2011 22:25:04 +0100")

"Jose A. Ortega Ruiz" <jao@gnu.org> writes:
>>    (use-modules (url://a-url.com library module #:optional a-rev-number))
>
> FWIW, i think this is a bad idea.  It intermingles two concerns that are
> othogonal, namely installing a package and using it.

I very strongly agree with jao.  Systems like this, e.g. Python Eggs,
have been a major headache for distributions to deal with.  Debian
actually takes the time to disable this automatic downloading and
installing functionality from their Python packages, and I'm glad for
it.  I am very security conscious, and the thought of software being
automatically installed "on-demand" from untrusted sources when I run a
program, or maybe even when I first use some particular functionality of
that program, is very disconcerting.

Maybe not everyone wants this, but as a Debian and gNewSense user, I
want my distribution to be an intermediary for most of the software I
use.  I trust them more than I trust most upstreams to ensure that the
software has been somewhat vetted for license issues, security problems,
anti-features, etc.  I want my distribution to be able to modify the
packages as necessary to make them work well together and with the rest
of the system.  I also want experimental distributions to be able to
make significant changes to packages to fit within their new ideas of
how the system should be set up.

Furthermore, there are many thorny issues involved with package
management that are very hard to get right, and most of the new crop of
language-specific package systems like this are half-baked at best.

For example, how do you ensure security?  Debian has a reasonably well
thought out system for using digital signatures for this.  How will we
handle it?

Also, how will we handle versioning?  It is very hard to do this
properly.  Sometimes you want the cutting-edge version of something, and
sometimes you want stability.  It is not enough to simply designate a
stable version of each individual package.  A stable system requires
that all the individual pieces have been tested together as a whole, as
is done in Debian and other distros.  How will we handle it?

I don't mean to be a wet blanket, because I can certainly see the appeal
of a system like this, but let's please be careful not to repeat the
many mistakes that other similar systems have made.  It is a very thorny
problem.

    Regards,
      Mark



  reply	other threads:[~2011-03-08  1:10 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-03-07 20:23 summer of code ideas Mike Gran
2011-03-07 21:25 ` Jose A. Ortega Ruiz
2011-03-08  1:10   ` Mark H Weaver [this message]
  -- strict thread matches above, loose matches on Subject: below --
2011-03-08  1:45 Mike Gran
2011-03-07 19:51 Andy Wingo
2011-03-07 20:12 ` Noah Lavine
2011-03-07 21:33   ` Ludovic Courtès
2011-03-07 22:11     ` Noah Lavine
2011-03-07 22:27       ` Ludovic Courtès
2011-03-07 22:37         ` Noah Lavine
2011-03-08 13:00           ` Ludovic Courtès
2011-03-07 20:40 ` Noah Lavine
2011-03-07 20:46   ` Andy Wingo
2011-03-07 21:27     ` Ludovic Courtès

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://www.gnu.org/software/guile/

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

  git send-email \
    --in-reply-to=87oc5mxvrq.fsf@netris.org \
    --to=mhw@netris.org \
    --cc=guile-devel@gnu.org \
    --cc=jao@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.
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).