On Thu, 18 Nov 2010, Ville Skyttä wrote:
> On Wednesday 17 November 2010, Kevin Kofler wrote:
>> Ville Skyttä wrote:
>> > I'd get rid of the versioned javadoc dir altogether, and simply install
>> > to %{_javadocdir}/%{name}. Unversioned is good for bookmarking and
>> > javadoc crosslinking.
>>
>> One thing you have to be careful of, no matter which way you decide, is
>> that you MUST NOT change a directory to a symlink or the other way round
>> or RPM will get terribly confused on upgrades.
>>
>> (There are bizarre (and easy to get wrong) scriptlet workarounds that can
>> be used, but avoiding the mess in the first place is probably the best
>> solution.)
>
> In this case it's the unversioned dir we want to stay around, so the
> scriptlet doesn't have to be any more bizarre than something like this which
> IMO isn't that bad (certainly not bad enough to stop implementing the above
> plan IMO), and would only be needed in *-javadoc that created an unversioned
> symlink, either owned by the package as usual or created "in the wild" in
> %post:
>
> %pretrans javadoc -p <lua>
> -- TODO: remove this scriptlet in F-17
> os.remove("%{_javadocdir}/%{name}")
It's not the script itself that's bad and bizarre, it's the entire
%pretrans mechanism that's problematic.
%pretrans runs before fingerprinting (this is required for the
directory/symlink replacing tricks to work at all), which means that the
transaction can abort due to file conflicts /after/ %pretrans scripts have
already modified the system. A further complication is that yum runs a
test-transcation first, where %pretrans (obviously) doesn't run, so it can
fail with file conflicts on the test transaction that wouldn't exist if
%pretrans had run.
While %pretrans script /can/ be used to work around the symlink/directory
issue to some extent, it should be only considered as a very last resort.
So, think hard before making a choice that might involve
directory<->symlink transitions, and certainly don't /design/ on using
%pretrans for this.
- Panu -
--
devel mailing list
[email protected]
https://admin.fedoraproject.org/mailman/listinfo/devel
