Hi Tyson, Am Donnerstag, den 18.03.2010, 11:34 -0400 schrieb Tyson Whitehead: > On March 17, 2010 12:55:25 Joachim Breitner wrote: > > Because if we’d put the whole ghc6 package name there, upon a ghc6 > > transition, even a minor one like 6.12.1 → 6.12.2 > > * we could not binNMU the library package but would have to manually do > > sourceful uploads of each package, adjusting the package name. > > * each upload would pass through NEW > > > > So the cost involved would be just too much. > > > > (AFAIK, the names of the packages must not be changed during a regular > > build.) > > I did some more reading of various Debian documents, and I can see how passing > through NEW would be a problem. I'm not sure I'm understanding your binNMU > comment though. Are you just saying then that you can't binNMU derived > packaged after a GHC version change, if the version is in the package name > (i.e., the same problem -- change in package name pushes it through NEW). binNMU means to make the build daemons automatically increase the version number (using +b1) and build the package again, _without modifying the source_. This is very convenient, as a large amount of builds can be triggered easily. But as the source must not change, we can not handle anything that changes package names with a binNMU. > In any event, I was thinking some more about it and might have solution: > > - stick with the libghc6-*-dyn package as is (no version in the name) > - add a libghc6-*-dyn-old package automatically generated by combining the > contents of the previous libghc6-*-dyn and libghc6-*-dyn-old packages > > This way all the previous versions (you could limit how many versions if you > wanted) are available in the libghc6-*-dyn-old package, so upgrading to the > latest libghc6-*-dyn package does not have to force a reinstalling of all > dynamic binaries on the system, thus breaking the synchronization problem. > > If the hash was included in the directory names, this scheme would even make > it possible to have multiple versions for the same compiler version. In effect > you would be doing the same thing as is done with C libraries (i.e., one > package contains the routines for several ABI versions, except the > differentiating is done at the directory level instead of inside the library). This way, to be able to build haskell-*, you would need to have libghc6-*-dyn installed, to copy the contents of previous versions. This will be hard to bootstrap (but not undoable). But another problem will make this probably unacceptable for Debian: The package libghc6-*-dyn-old will ship code built from a previous version of the source, which is no longer available in Debian. This is a breach of most current licenses. Also, this system seems to be relatively fragile to me. I think the best we can do at the moment is providing libghc6-*-dyn packages just like wo do provide the -dev package (or even include it in the -dev package). Locally built programs will have to be rebuilds after the admin updates a -prof package. Packaged programs will either be built statically as they are now (especially build tools), or be linked dynamically and be treated just like libraries when it comes to binNMUs etc. Our current system of Provides and Depends will ensure that the programs are always working on the users system. 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