Peter Simons wrote:

...

I think that we should remove the data files completely from the packages and only host them at a well-known URL (on kiwilight.com or haskell.org).

The notion that those files reside on a remote server concerns me a little, because it means that reproducibility goes, basically, straight out of the window. If you run cabal2arch to generate a PKGBUILD, and then run the exact same command just a few seconds later, it might generate a different PKGBUILD just because some invisible file has changed on a remote server at the other side of the earth. That property feels like it's bound to create surprises for people. Also, this change would reduce the amount of information expressed by cabal2arch's version number even further into the direction of "zero" than it already is.

I agree with these concerns. The files are essentially configuration files for cabal2arch and they should be included in the cabal2arch package. They should also be available online for direct download. I think the best way to do this is to host them separately on-line as already suggested, but they should be versioned. They could then be specified in the "source" array of the cabal2arch PKGBUILD. This would ensure reproducibility in any given version of cabal2arch while still making those files available for general use. The versions of both files could be made to coincide with cabal2arch versions to keep the cabal2arch PKGBUILD simple, e.g.: source=(..., "http://example.com/data/ghc-provides.${pkgver}.txt",...) (I'm assuming that the server would have compression enabled, otherwise I would use an archive.) Otherwise, if we expect to use those files in other packages then perhaps they should receive their own package (similar to the pacman-mirrorlist package). cabal2arch could still specify a version of that package as a dependency, if needed. Regards, Xyne

On 07/01/11 09:35, Peter Simons wrote:

Hi Magnus,

...

https://github.com/archhaskell/cabal2arch/issues#issue/20

thank you for tackling this problem.

...

I think that we should remove the data files completely from the packages and only host them at a well-known URL (on kiwilight.com or haskell.org).

The notion that those files reside on a remote server concerns me a little, because it means that reproducibility goes, basically, straight out of the window. If you run cabal2arch to generate a PKGBUILD, and then run the exact same command just a few seconds later, it might generate a different PKGBUILD just because some invisible file has changed on a remote server at the other side of the earth. That property feels like it's bound to create surprises for people. Also, this change would reduce the amount of information expressed by cabal2arch's version number even further into the direction of "zero" than it already is.

The file online would be the correct one, so if you run cabal2arch twice and the second time the file has been updated, then the PKGBUILD resulting from the second run is more correct than the one from the first run. Would the file really change so often that this scenario is common? If you care about reproducibility then you can always instruct cabal2arch to use a local file. In short, I don't have any of the concerns you have :-) On the other hand, I'm perfectly fine with including the files in the cabal2arch package and install them (though they might as well be compiled into the executable in that case). All the while keeping the ability to specify which files to use on the command line. /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus@therning.org jabber: magnus@therning.org twitter: magthe http://therning.org/magnus

On 08/01/11 08:36, Rémy Oudompheng wrote:

On 2011/1/7 Magnus Therning wrote:

...

I've just created issue 20[1] for cabal2arch. Basically there's a problem with the data files provided in archlinux, but used in cabal2arch. Having data files in a library package breaks our basic assumption that executables only need to makedepend on the libraries it uses.

In this case I still think that we should remove the data files completely from the packages and only host them at a well-known URL (on kiwilight.com or haskell.org). cabal2arch should then default to use that URL, for development and testing it might be interesting to add a command line switch to load it from another location, a URL or file.

For now I assigned the issue to Remy. Feel free to re-assign it if you want to.

Since I had the patches on my local repository, I pushed them upstream. For the moment, it still uses files, because I also think cabal2arch should remain usable without an internet connection, and have reproducibility properties. However, it's only a matter of seconds to make it use http://andromeda.kiwilight.com/~remy.oudompheng/arch-haskell/default/ instead.

Fair enough, there is overwhelming opposition to my idea of using data files from URLs by default so I'll stop suggesting it :-) Rémy, does this change fix issue 20[1] completely then? If so I'll close it, unless you beat me to it ;-) /M [1] https://github.com/archhaskell/cabal2arch/issues#issue/20 -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus@therning.org jabber: magnus@therning.org twitter: magthe http://therning.org/magnus

On 2011/1/9 Peter Simons wrote:

Hi Rémy,

 > Since I had the patches on my local repository, I pushed them  > upstream.

thank you for the fixes. I have another patch that simplifies the library a bit: IMHO, we can drop the 'ArchPackage' data type, because it's unused. Or do you think we'd still need that one?

I added it because I thought it was a better type for the output of the conversion function (since the output is really a PKGBUILD + Maybe an install script), but I didn't use it yet. I'd prefer keeping it for the moment. -- Rémy.

On 2011/1/10 Peter Simons wrote:

Hi Rémy,

 > I added [ArchPackage] because I thought it was a better type for the  > output of the conversion function (since the output is really a  > PKGBUILD + Maybe an install script), but I didn't use it yet. I'd  > prefer keeping it for the moment.

you are right. I agree that this type is a good choice to represent the result of a cabal-to-pkgbuild conversion.

At the same time, I am a little concerned about the seemingly increasing amount of dead code in the ArchLinux library. Note that the ArchPackage type has been added on 2010-10-15, and since then it's been sitting there unused. Furthermore, note that the export list for PkgBuild.hs doesn't mention that type. So, not only is it unused, it's actually impossible to use because the outside world can't access it.

Clearly, the ArchPackage type is part of an ongoing effort to re-factor the cabal2pkg function. That is a good idea and I am totally in favor of it. I would like to suggest, however, that this kind of re-factoring is performed in a branch and merged into 'master' only after it's complete.

Does that sound reasonable?

Yes, perfectly reasonable. -- Rémy.