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
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