Hi John, thanks for joining the discussion. Am Montag, den 02.08.2010, 11:49 -0700 schrieb John MacFarlane: > - the gitit and filestore packages will both be supplying this file -- > I don't know enough about debian to know if this will cause problems, > but wouldn't you get a warning that the package you're installing > is overwriting an existing file? this is a valid point. I guess the filestore API does not provide a way for the calling application to tell it where the file is stored, so that gitit could use a gitit-specific location such as /usr/share/gitit/git-hook? > - it's going to be a maintenance headache, since the maintainer of > the gitit package will have to make sure that the post-update file > is updated in gitit whenever it is changed in filestore. Lets assume for a moment that filestore changes the interface to the hook, i.e. the old filestore will not work with the new hook and the old hook will not work with the new filestore. Variant A: libghc6-filestore-data package. 1. gitit links against old filestore 2. filestore gets updated 3. users installing gitit run old filestore code, but new hook → breakage Variant B: hook in gitit. 1. gitit links against old filestore. while building the package, the package scripts copy the hook file from libghc6-filestore-dev (where it is placed somewhere soley to be copied from) into the gitit package. 2. filestore gets updated 3. users installing gitit run old filestore code and old hook → everything is fine If the maintainers copies the file manually, then this might be a cause for errors, but otherwise the scheme is the same. Did you consider a third variant: Actually linking the hook into your code, as a (Byte)String constant, and writing it out to disk when creating a gitit-enabled repository? Then there is no such problem at all, and the hook is always tied directly to the code. (Probably does not work as you’d need to update the hook when you upgrade the code, right?) Do you copy the hook to the git repo or symlink it to a central location. > In addition, I think there's good reason not to address this problem > in a way that is specific to gitit. After all, the same problem will > affect any package that (a) supplies an executable that should be installable > without Haskell libraries, and (b) depends on libraries that rely on data > files. I'm sure there are other examples than gitit. If there aren't now, > there will be soon. So it might be worth putting some thought into how to > proceed. > > One possible solution, which would require modifying haskell-devscripts, > would be this. If a library (say, filestore) has data files > that it accesses via Paths_filestore, then there could be an additional debian > package for it that just installs the data files, so we'd have: > > libghc6-filestore-dev > libghc6-filestore-prof > libghc6-filestore-data > > libghc6-filestore-dev and gitit could both depend on libghc6-filestore-data, > which would have no further dependencies of its own. > > It seems to me that this would be a clean solution to the problem. as pointed out above, this has issues while we employ statical linking. We could alleviate this a big by having strict dependencies onto the -data package, but I’d like to avoid them. 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