On Tuesday 28 April 2009 08:12:50 Sean Flanigan wrote:
From irc the other day:
<akurtakov_> artifact.xml is simply unusable because it has paths from
build time in it
<akurtakov_> and the repo is invalid with only content.xml
I can see that artifacts.xml does contain some build-time filesystem
paths, but I don't really understand the problem, since Eclipse doesn't
seem to care too much.
Are there any old discussions about this that I should be reading,
instead of bothering the list?
I'm interested because I have found that suitably massaged
(optional+non-greedy) P2 metadata can help Eclipse to cope with the
Babel langpacks and the fragment plugins they contain:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=256430
So I would like to include the P2 metadata with eclipse-nls (RPMs for
the Babel langpacks).
1. Does Eclipse in fact care about these paths? In which case, why does
P2 work (occasionally!) on my machine, with completely different
filesystem paths?
There is a bug in 3.4 which keeps dropins recognized even when
artifact.xml is
wrong or entirely missing and the folder was processed as if there was an
.eclipseextension file in it. But this is fixed so such repo is just marked as
invalid with 3.5.
2. Is there a Fedora packaging rule that says build-time paths are
not
allowed into packages, perhaps because they make it impossible to
reproduce byte-identical builds?
3. Assuming one of the above is true: Could we sed-patch the
artifacts.xml file to remove/normalise the build path?
4. Alternatively, would it help if we were to use the P2 director to
install eclipse-nls from a local update site, thus installing the
features the P2 way, rather than using dropins?
I think that Andrew was working on some scriptlets to use in %post so plugins
get installed in the p2 way. This should help fixing the problem
Alex
Thanks
Sean