On Tue, Oct 28, 2008 at 8:32 AM, David Roundy wrote:

Yes, it's important for me to be able to use the latest darcs on my debian stable computers.

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. It's this reason that has always forced me to run testing and pull packages from unstable while still building some things from source. I hear things are better in the Ubuntu world. So far, the only platforms we need to worry about ghc6.6 on are OpenBSD and Debian Stale. We could use is a little chart with distros along the top, GHC versions along the side and notes in the middle about when the distro will be upgrading to the next release. Thanks, Jason

Hi, On Tue, Oct 28, 2008 at 10:11:53AM -0700, Jason Dagit wrote:

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. It's this reason that has always forced me to run testing and pull packages from unstable while still building some things from source. I hear things are better in the Ubuntu world.

AFAIK, ghc-6.6 is two years old. I wouldn't call this old. Ciao, Kili -- For some reason some communities are using the uptime of a machine as a compensation for something else being small. -- Artur Grabowski (http://www.blahonga.org/~art/diffs/)

On Tue, Oct 28, 2008 at 4:42 PM, Juliusz Chroboczek wrote:

...

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.

Jason,

I know it's frustrating, but please understand where we're coming from.

There are a number of servers that support our research. The important thing to understand is that nobody is paid full-time to maintain these servers. For example, in our lab, the production servers are maintained by one technician that has a number of other machines in charge, the server for experimental stuff is maintained by myself and one postdoc in our copious free time.

As far as the server I'm in charge of is concerned, we apply security patches in a timely manner, and we try to check the logs on a weekly basis. Other than that, we avoid touching it.

Once every two years, usually in August, we move it from oldstable (head - 2) to stable (head - 1). We then spend a couple of weeks reading the logs daily and ironing out any remaining issues. (The production servers are managed even more conservatively, the DNS server has only just switched to stable, the web/SMTP server is still running oldstable.)

This point reminds of how the thread drifted from my original intent. I wanted to know if anyone who is using distros with 6.6 need to be able to build current releases of darcs from source. This is of course different than needing darcs. These distros have a version of darcs that shipped with them. If you're willing to build darcs from source, where do you draw the line? Given your contributions to darcs I would understand if you said, "I always want to run the latest stable release of darcs." That would make sense to me. If darcs2 format compatibility is an issue then building the 2.x stable releases up to this point should work. It's future releases that I would want to consider dropping support for 6.6. And we will drop 6.6 support eventually. The question is when is the earliest time we can do that. Jason

On Thu, Oct 30, 2008 at 1:20 PM, Juliusz Chroboczek wrote:

...

I wanted to know if anyone who is using distros with 6.6 need to be able to build current releases of darcs from source.

If there turns out to be a significant issue with Darcs 1, I need to be able to build a recent version of Darcs in my Debian stable chroot.

I see. If you're using the darcs 1 binary I would encourage you to upgrade. If you meant darcs 1 repository format then I would encourage you to consider darcs 1 hashed repository format. You don't even have to upgrade the public facing repo. Just 'darcs get --hashed ...'.

The alternative is to build a static version of Darcs that I can install on my stable (soon to be oldstable) servers. Last time I checked, building static Darcs didn't work.

Interesting. Yes, building darcs statically is something we should probably do on the build bots.

The alternative to both alternatives is to switch to git.

Right. But I hope you're not saying that because you find this thread upsetting. The whole point was just to find out if 6.6 is significant to people and that has already been established. Thanks, Jason

On Thu, Oct 30, 2008 at 03:08:29PM -0700, Don Stewart wrote:

dagit:

...

On Thu, Oct 30, 2008 at 1:20 PM, Juliusz Chroboczek wrote:

...

...

I wanted to know if anyone who is using distros with 6.6 need to be able to build current releases of darcs from source.

If there turns out to be a significant issue with Darcs 1, I need to be able to build a recent version of Darcs in my Debian stable chroot.

I see. If you're using the darcs 1 binary I would encourage you to upgrade. If you meant darcs 1 repository format then I would encourage you to consider darcs 1 hashed repository format. You don't even have to upgrade the public facing repo. Just 'darcs get --hashed ...'.

...

The alternative is to build a static version of Darcs that I can install on my stable (soon to be oldstable) servers. Last time I checked, building static Darcs didn't work.

Interesting. Yes, building darcs statically is something we should probably do on the build bots.

Statically linked darcs should be trivial with the cabal version.

The bug is in debian's libcurl. David

Juliusz Chroboczek 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.

On Tue, Oct 28, 2008 at 5:13 PM, Trent W. Buck wrote:

"Jason Dagit" 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.

What is the cost/benefit for providing a backport? Suppose we wanted to provide a backport so that we could drop a dependency on old software. Could we realistically tell users to get an update from the backport? Then we still have OpenBSD users. I think we don't have a realistic solution other than to deal with the maintenance burden of supporting antique software. Thus I think the version/upgrade matrix is handy so we can plan/schedule when it is safe to drop support. Thanks! Jason

Duncan, I believe the major darcs issue is the changed GADT implementation between 6.6, so that neither 6.6 or 6.8 is a superset/subset of the other - leading to a situation where they have to use a common subset of both. Thanks Neil

-----Original Message----- From: haskell-cafe-bounces@haskell.org [mailto:haskell-cafe-bounces@haskell.org] On Behalf Of Duncan Coutts Sent: 29 October 2008 10:29 am To: dagit@codersbase.com Cc: darcs-users@darcs.net list; haskell-cafe Subject: Re: [Haskell-cafe] Poll: Do you need to be able to build darcs from source on GHC 6.6?

...

Hello,

I would like to find out if any darcs users who build from

On Mon, 2008-10-27 at 19:24 -0700, Jason Dagit wrote: the source

...

are still using ghc 6.6?

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:

flag external-foo description: Use the external package foo, or the bundled version default: True

executable whatever

if flag(external-foo) build-depends: foo == 1.* else hs-source-dirs: lib/foo

And I think that's it for simple external packages (though I've not tested). For external packages that use C files or link to C code it needs a bit more to bundle, but not a lot more. In either case the internal code should be able to import the standard module name without using any CPP.

The advantage of course is less cpp, a single API, and not having to test two implementations (because the bundled impl is the same as the external impl).

Duncan

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

============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ==============================================================================

On Wed, Oct 29, 2008 at 11:17:35AM -0000, Mitchell, Neil wrote:

Duncan,

I believe the major darcs issue is the changed GADT implementation between 6.6, so that neither 6.6 or 6.8 is a superset/subset of the other - leading to a situation where they have to use a common subset of both.

No, the 6.6 gadts are nicer than the 6.8 gadts, but the common subset is pretty large. Duncan has the issue right: it's the desire to reduce the number of dependencies that's at issue. And as far as bundled versions, it's the desire to *remove* a bundled version that's apparently at issue. I'm not sure why this is considered desirable, but apparently some folks feel strongly about this. David

David Roundy writes:

And as far as bundled versions, it's the desire to *remove* a bundled version that's apparently at issue. I'm not sure why this is considered desirable, but apparently some folks feel strongly about this.

Could someone please summarize what code is currently bundled with darcs that isn't darcs? I had the impression that most of it was "in house" code that had/has not been formalized into a separate libraries yet (e.g. an FFI for zlib, byte strings before they were librarified). To me, that's different from a bundled (convenience) copy, which is where you basically download libfoo's tarball, unpack it in your source tree, and then do "darcs rec -lam 'Install copy of libfoo 5.1'".

On Thu, Oct 30, 2008 at 12:16:17PM +1100, Trent W. Buck wrote:

David Roundy writes:

...

And as far as bundled versions, it's the desire to *remove* a bundled version that's apparently at issue. I'm not sure why this is considered desirable, but apparently some folks feel strongly about this.

Could someone please summarize what code is currently bundled with darcs that isn't darcs? I had the impression that most of it was "in house" code that had/has not been formalized into a separate libraries yet (e.g. an FFI for zlib, byte strings before they were librarified).

Yes, that's what I was referring to. The bytestring library is a descendant of the FastPackedString module that is still in darcs. Recently Ganesh added the ability for darcs to use bytestring instead if its own code, and dons has submitted code to remove FastPackedString in favor of bytestring.

To me, that's different from a bundled (convenience) copy, which is where you basically download libfoo's tarball, unpack it in your source tree, and then do "darcs rec -lam 'Install copy of libfoo 5.1'".

Yes, I agree. But continuing to keep our own code has the same sorts of benefits that bundling other libraries has (without the legal hassle). -- David Roundy http://www.darcs.net

Duncan Coutts 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.