Dear Arie, thanks for your response. Am Sonntag, den 08.04.2012, 14:09 +0200 schrieb Arie Middelkoop: > On 06-04-12 13:52, Joachim Breitner wrote: > > when upgradeing uuagc for Debian, I’d like to avoid packaging > > uuagc-bootstrap, as it is just a copy of uuagc (right?). Given that > > uuagc already exists in Debian, can a new uuagc packages build using > > that? If so, how? > > Let me first say that the package dependencies of uuagc are rather > nasty, and that I would be open to suggestions for improvement. The > current setup is the best we managed to come up with so far. have you considered the approach taken by other self-depending programs such as happy? $ cabal unpack happy Downloading happy-1.18.9... Unpacking to happy-1.18.9/ $ find happy-1.18.9/dist/ happy-1.18.9/dist/ happy-1.18.9/dist/build happy-1.18.9/dist/build/happy happy-1.18.9/dist/build/happy/happy-tmp happy-1.18.9/dist/build/happy/happy-tmp/AttrGrammarParser.hs happy-1.18.9/dist/build/happy/happy-tmp/Parser.hs It ships the generated files in the dist/ directory, i.e. where Cabal expects them. This allows Cabal to build happy without using this, but also allows the user to easily build directly from source by removing the dist/ directory, something that Debian does. > The 'uuagc-bootstrap' package is indeed some 'stable' copy of the > original package, except that it contains the generated sources instead > of the original sources, has a different executable name and a different > entry-point when used as a library. The last two points are important to > prevent collisions when building the actual uuagc package. I don’t see the advantage over putting the generated sources, together with the original sources, in the main uuagc package? > So, if you want to use an existing uuagc to build uuagc, it's still > possible with a slight patch. First, the dependency on the bootstrap > package must be removed from the cabal description, but do not add a > dependency to an older uuagc to the cabal description! You'll need an > existing uuagc somewhere, but that you should be able to express via > Debian's package manager. > > You can then simply put in UUAGC's Main.hs: > > main = defaultMainWithHooks (uuagcUserHook' "path-to-old-uuagc") > > Note: you'll get a deprecation warning because - as mentioned earlier - > the preferred method is building via uuagc-as-a-library instead of using > a given executable. Anyway, you can ignore this warning. Thanks, works great. Would it be possible to make this configurable using a Cabal flag, so that we don’t have to patch the Cabal and Setup file? > However, I'm not sure what you would gain by doing this. The > uuagc-bootstrap package is a conventional haskell package, so it should > be easier to handle than fiddling around with an older version of uuagc. It is an unfortunate misconception in the Haskell world that just because it is cheap to upload another package to Hackage, it is also cheap for the distributions. For various reasons, every additional package causes manual work. In addition, packaging uuagc-bootstrap in Debian would violate various rules and conventions, such as to not have multiple copies of the same code package, and also we would not be building uuagc from source (but rather from some generated file that supposedly was built from source by someone else). The fact that Debian tries hard to build everything from source is an important QA measure to guarantee that every user can easily fetch the source, modify it, build it and be done. If we were not to build the source from source it is likely that actually building from source bitrots and will not be possible automatically. Will it always be possible to build released version n+1 of uuagc with version n? Greetings, Joachim -- Joachim "nomeata" Breitner Debian Developer nomeata@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C JID: nomeata@joachim-breitner.de | http://people.debian.org/~nomeata
Attachment:
signature.asc
Description: This is a digitally signed message part