[Haskell-cafe] Re: Poll: Do you need to be able to build darcs from source on GHC 6.6?

2008-11-02 Thread Achim Schneider
Juliusz Chroboczek [EMAIL PROTECTED] wrote:

 No.  That was just a way of pointing out that other revision control
 systems do not have such complex build dependencies.

*cough*
% export USE=doc gtk iconv perl subversion bash-completion cgi curl cvs
emacs mozsha1 ppcsha1 threads tk vim-syntax webdav xinetd
% emerge git --emptytree -p |wc -l
381

% export USE=-doc gtk iconv perl subversion bash-completion cgi curl
cvs emacs mozsha1 ppcsha1 threads tk vim-syntax webdav xinetd
% emerge git --emptytree -p |wc -l
329

% export USE=-doc -gtk -iconv -perl -subversion -bash-completion -cgi
-curl -cvs -emacs -mozsha1 -ppcsha1 -threads -tk -vim-syntax -webdav
-xinetd emerge git --emptytree -p |wc -l
% emerge git --emptytree -p |wc -l
57

% USE=doc emerge darcs --emptytree -p | wc -l
329

(that's mostly because stuff like latex pulls the whole of x11 and gtk
with my current settings... I can't be arsed to figure all of that
out right now)

% USE=-doc emerge darcs --emptytree -p | wc -l
79


Now you can say that A severely crippled version of git has less source
dependencies, but don't ever claim that the build dependencies are
less _complex_. 17 package-specific use flags are rather extreme.

-- 
(c) this sig last receiving data processing entity. Inspect headers
for copyright history. All rights reserved. Copying, hiring, renting,
performance and/or quoting of this signature prohibited.


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


[Haskell-cafe] Re: Poll: Do you need to be able to build darcs from source on GHC 6.6?

2008-10-29 Thread Trent W. Buck
Duncan Coutts [EMAIL PROTECTED] writes:
 I'd just like to point out (again ;-) ) than it's not that hard to
 support older platforms. The only constraint is that people not squeal
 at the sight of bundled code. The bundling can be done in such a way
 that it's not a maintenance burden, indeed it can remove the need to
 maintain internal equivalents of external libs.

 For example for an external package foo, we could put the latest stable
 version of it in lib/foo and in the .cabal file say something like:

As the Debian packager, including convenience copies of build dependency
libraries in the stable tarballs increases my workload because

- Debian Policy requires that I not use them.  If the ./configure
  prefers the convenience copies over the ones found on the system, that
  means I have to write extra code in debian/rules to force the use of
  the system copies.

- Debian Policy requires that all files in the source tarball -- even
  libraries that I don't actually compile against -- have their
  copyright and license information declared in debian/copyright.  This
  means that even if everybody knows libfoo is GPL, I have to audit
  the convenience copy to make sure that every significant work (read:
  file) in the convenience copy has a clear license declaration to that
  effect, and to document any exceptions.

  Alternatively, I can create my own stable tarball of darcs by
  unpacking the one Eric makes, removing the convenience copies, and
  then re-tarring it.  But this is fiddly and normally only done when
  the upstream tarball contains work that Debian won't or can't
  (legally) distribute.

Therefore while I understand the argument for convenience copies, I'd be
obliged if they were kept to a minimum.

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


[Haskell-cafe] Re: Poll: Do you need to be able to build darcs from source on GHC 6.6?

2008-10-28 Thread Trent W. Buck
Jason Dagit [EMAIL PROTECTED] writes:
 Debian is nice in some ways and it's really great that stable lives up
 to its name, but I am sad that Debian has such old software for so
 long.

Those two properties are strongly correlated.

There is backports.org for cases where you want to cherry-pick a handful
of packages for which stability is less important than newness.  Of
course, GHC 6.8 isn't on backports.org at present.  That means either
it's non-trivial to backport, or nobody has volunteered the time.

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


[Haskell-cafe] Re: Poll: Do you need to be able to build darcs from source on GHC 6.6?

2008-10-28 Thread Achim Schneider
David Roundy [EMAIL PROTECTED] wrote:

 On Wed, Oct 29, 2008 at 12:11:22PM +1100, Trent W. Buck wrote:
   Thus I think the version/upgrade matrix is handy so we can
   plan/schedule when it is safe to drop support.
  
  In an ideal world, we just make sure it builds with the latest
  tools, and let the users of stable distros worry about telling us
  if it breaks against whatever versions they care about.
 
 No, in the idea world we'd try to be supportive of our contributors
 and maintainers by not requiring that they install the latest tools.

No, in the ideal world bleeding edge is stable.

-- 
(c) this sig last receiving data processing entity. Inspect headers
for copyright history. All rights reserved. Copying, hiring, renting,
performance and/or quoting of this signature prohibited.

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


[Haskell-cafe] Re: Poll: Do you need to be able to build darcs from source on GHC 6.6?

2008-10-28 Thread Trent W. Buck
Trent W. Buck [EMAIL PROTECTED] writes:

 On Wed, Oct 29, 2008 at 12:39:28PM +0900, Stephen J. Turnbull wrote:
 Trent W. Buck writes:
 
   In an ideal world, we just make sure it builds with the latest tools,
   and let the users of stable distros worry about telling us if it
   breaks against whatever versions they care about.
 
 This is very disappointing coming from (some) developers of *version
 control software*!  You'd think they, of all software developers,
 would be sympathetic to the need to, well, control versions!

 Let me clarify that the above are my *personal* opinions, and I'm not
 really involved in the Darcs Haskell code -- just the surrounding
 build and documentation infrastructure.

 I'm speaking more from my role as a Debian maintainer and user than as
 a member of the Darcs comunity.

Actually, even more than that I'm speaking as someone who for years
tried to keep shell scripts portable and POSIX clean and working even on
ten-year-old versions of Solaris... before deciding that I was investing
way too much time testing on those systems considering approximately
zero of my users ran them.  So I said fuck it, I'll use bash and assume
GNU coreutils, and if it breaks on someone's system, they'll tell me.

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe