Hi Ian, Am Dienstag, den 14.06.2011, 18:31 +0100 schrieb Ian Jackson: > Joachim Breitner writes ("Merging three direcories in postinst"): > > Will it still cleanly remove files that were installed by > > libghc-foo-doc into /usr/lib/ghc-7.0.3/haddock/ when libghc-foo-doc > > is removed? > > Yes, it will. It will also (try to) remove the symlink when it thinks > /usr/lib/ghc-7.0.3 becomes empty.
Great. This solves one of my worries (how to get rid of the symlinks when they are not needed any more). > However, dpkg will not know that > /usr/lib/ghc-7.0.2/haddock/foo.haddock (in old libghc-foo-doc) > and > /usr/lib/haddock/foo.haddock (in old libghc-foo-doc) > are the same file. This will not normally be a problem as dpkg will > ihappily "overwrite" the "unexpected" other file, but you should be > aware of it. Because the file name contains the package name, there can never be a case of two installed packages installing files to paths that look different but are the same after symlinking. > > for dir in /usr/lib/ghc-7.0.2/haddock /usr/lib/ghc-7.0.3/haddock > > do > > if test -d $dir > > then > > mv $dir/* /usr/lib/haddock > > rmdir $dir > > ln -s ../haddock $dir > > fi > > done > > This code is buggy because it will always trigger since test -d will > be true for a symlink to a directory. Thanks for the pointer. It was only pseudo-pseudo-code at this point, of course. > Also you might want to think about what you want to happen if the same > file is found in two or more of > /usr/lib/haddock > /usr/lib/ghc-7.0.2/haddock > /usr/lib/ghc-7.0.3/haddock > > In general I think you have a tenable approach here. But you should > do thorough testing; particularly, you should do testing with > "dpkg -i" and "dpkg --remove" in arbitrary orders, and you should do > testing of what happens if your fixup script falls over halfway > through (eg, put a sleep in it and ^Z then kill -9 the whole dpkg > process stack). > > It is important that the sh code you write is idempotent and the > dependencies are all correct. I suggest you come back here (or to > debian-dpkg) and ask for another review when you have a more concrete > implementation. I am a bit worried about getting the removal part right, and of course there are so many possible failures. Maybe it is cleaner to just dpkg-divert the .haddock files to the location in /usr/lib/haddock? I thought I need to access them in the old locations as well, but the path mentioned is in an arch:any, so it will be correct (/usr/lib/haddock) after the obligatory round of binNMUs when the next ghc version is installed. But since dpkg-divert cannot divert directories, I’d either have to collect the full list of broken files from the Contents files and hard-code them, or do it via a trigger, which also seems to be overkill for a work-around. I guess I’ll give the postinst-symlink-approach a shot. Thanks for the advice, Joachim -- Joachim "nomeata" Breitner Debian Developer nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata
signature.asc
Description: This is a digitally signed message part