diff options
Diffstat (limited to 'zarb-ml/mageia-dev/2013-January/021293.html')
| -rw-r--r-- | zarb-ml/mageia-dev/2013-January/021293.html | 227 |
1 files changed, 227 insertions, 0 deletions
diff --git a/zarb-ml/mageia-dev/2013-January/021293.html b/zarb-ml/mageia-dev/2013-January/021293.html new file mode 100644 index 000000000..80025df5e --- /dev/null +++ b/zarb-ml/mageia-dev/2013-January/021293.html @@ -0,0 +1,227 @@ +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> +<HTML> + <HEAD> + <TITLE> [Mageia-dev] Help with package + </TITLE> + <LINK REL="Index" HREF="index.html" > + <LINK REL="made" HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Help%20with%20package&In-Reply-To=%3C50EBEBB7.4010401%40colin.guthr.ie%3E"> + <META NAME="robots" CONTENT="index,nofollow"> + <META http-equiv="Content-Type" content="text/html; charset=us-ascii"> + <LINK REL="Previous" HREF="021275.html"> + <LINK REL="Next" HREF="021134.html"> + </HEAD> + <BODY BGCOLOR="#ffffff"> + <H1>[Mageia-dev] Help with package</H1> + <B>Colin Guthrie</B> + <A HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Help%20with%20package&In-Reply-To=%3C50EBEBB7.4010401%40colin.guthr.ie%3E" + TITLE="[Mageia-dev] Help with package">mageia at colin.guthr.ie + </A><BR> + <I>Tue Jan 8 10:49:43 CET 2013</I> + <P><UL> + <LI>Previous message: <A HREF="021275.html">[Mageia-dev] Help with package +</A></li> + <LI>Next message: <A HREF="021134.html">[Mageia-dev] [338616] Use official tarball +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#21293">[ date ]</a> + <a href="thread.html#21293">[ thread ]</a> + <a href="subject.html#21293">[ subject ]</a> + <a href="author.html#21293">[ author ]</a> + </LI> + </UL> + <HR> +<!--beginarticle--> +<PRE>[Friendly request: Can you try and post in plain text only, not HTML too +please] + +'Twas brillig, and Juan Luis Baptiste at 07/01/13 19:32 did gyre and gimble: +><i> Hi Colin, +</I>><i> +</I>><i> On Mon, Jan 7, 2013 at 5:53 AM, Colin Guthrie <<A HREF="https://www.mageia.org/mailman/listinfo/mageia-dev">mageia at colin.guthr.ie</A> +</I>><i> <mailto:<A HREF="https://www.mageia.org/mailman/listinfo/mageia-dev">mageia at colin.guthr.ie</A>>> wrote: +</I>><i> +</I>><i> > Well, it worked on x86_64, but on i586 the symlinks are created under +</I>><i> > /usr/lib64/games/warsow/basewsw instead of +</I>><i> /usr/lib/games/warsow/basewsw +</I>><i> > but I don't understand why, it seems that for some reason, the +</I>><i> > %{_libdir} macro is expanding to /usr/lib64 on the BS. This is the +</I>><i> spec +</I>><i> > if someone wants to take a look: +</I>><i> > +</I>><i> > +</I>><i> <A HREF="http://svnweb.mageia.org/packages/cauldron/warsow-data/current/SPECS/warsow-data.spec?revision=338836&view=markup">http://svnweb.mageia.org/packages/cauldron/warsow-data/current/SPECS/warsow-data.spec?revision=338836&view=markup</A> +</I>><i> +</I>><i> %_libdir expands to the given architecture's libdir. On i586 it's +</I>><i> /usr/lib, on x86_64 it's /usr/lib64. +</I>><i> +</I>><i> +</I>><i> I know, that's why it's strange to me why when the package is built on +</I>><i> the BS the links end up on /usr/lib64 on the i586 package. +</I> +There is no "i586" package here, as the spec is noarch. There is only +one build and it's arch independent. I'll explain more below. + +><i> Looking at the spec, I think you're doing it a bit wrong. +</I>><i> +</I>><i> It's in the %post for a start which is wrong. It should be done as part +</I>><i> of package build, not install. Doing it during install will mean the +</I>><i> files are not "owned" by the package so users cannot tell where they +</I>><i> come from. +</I>><i> +</I>><i> +</I>><i> Well, that was just a suggestion from someone on this thread and it +</I>><i> looked to me like the right place too. On this particular case what I'm +</I>><i> doing here is not installing some files but creating some symlinks that +</I>><i> the other warsow package needs. +</I> +Hmm, I didn't see any other replies on the thread - must be broken +threading on my mail client :s + +So are the symlinks intended to link files from other packages here too? +This seems wrong if so. + + +><i> Also as you use %_libdir, your package cannot be noarch. +</I>><i> +</I>><i> +</I>><i> The "warsow-data" package contains the data files of the game which are +</I>><i> arch independent. The "warsow" package contains all the binaries and +</I>><i> libs, but to be able to run the game, the binary expects to find the +</I>><i> data files on the same directory where the libs are, if not then the +</I>><i> angelscript module will fail loading. So, what I'm trying to accomplish +</I>><i> is that when warsow-data is installed, symlinks of the files in the data +</I>><i> directory (/usr/share/warsow/basewsw/*) are created on +</I>><i> /usr/lib{64}/games/warsow/basewsw/. It works on x86_64 but on i586 is +</I>><i> creating the links on lib64 instead of lib and I don't get why, you saw +</I>><i> the code in the spec, I'm not hardcoding any path on it: +</I>><i> +</I>><i> +</I>><i> %define gamelibdir%{_libdir}/games/warsow +</I> + ^^^^^^^^^^ + +You hard code it right there. You cannot use _libdir in a noarch +package. _libdir depends on the arch used when building. It's +fundamentally incompatible with a noarch package. + +Remember macros are expanded at build time. So if your "noarch" package +is build on a 64bit build node, _libdir will be /usr/lib64, but if it +happens to be built by an i586 build node, then it'll be /usr/lib. You +simply cannot use the _libdir macro in a noarch package. + +Either you have to use some other form of detection of /usr/lib vs. +/usr/lib64 that will work at %post time (e.g. running uname -m) and then +use the right path (hard coded for each arch) accordingly. That way you +can keep your package noarch. + +That said, even the above suggestion will not actually work as you use +your gamelibdir definition in actual files included in the package +itself (in the %files section). Of course this looks like an empty +directory only included so you can add symlinks to it later so it should +be able to be refactored. + +><i> %post +</I>><i> #Add symbolic links of the contents of basewsw to the directory were the +</I>><i> #package warsow install the libs, if not then angelscript fails to load. +</I>><i> for i in %{_datadir}/warsow/basewsw/*; +</I>><i> do +</I>><i> file=`basename $i` +</I>><i> ln -sf $i %{gamelibdir}/basewsw/$file +</I>><i> done +</I>><i> +</I>><i> %postun +</I>><i> rm -rf %{gamelibdir}/basewsw +</I>><i> +</I>><i> +</I>><i> +</I>><i> If you want to use /usr/lib all the time then do so (if that's what the +</I>><i> game binary expects) via %{_prefix}/lib not via %_libdir. +</I>><i> +</I>><i> +</I>><i> +</I>><i> That's not the case, as explained before, the symlinks have to be +</I>><i> created at /usr/lib for i586 and at /usr/lib64 for x86_64, but on i586 +</I>><i> for some reason isn't doing it. +</I> +OK, so the fundamental issue you're encountering is trying to do this +from a noarch package! You cannot know about different architectures +automatically in a noarch package. + +I understand the principle of keeping arch-independent data in a noarch +package, but you cannot mix arch-specific and arch-independent here! + + + +So here is my recommendation: + +Either: + +a. Make it arch-specific and do the symlinking in %install. + +or + +b. Kill off gamelibdir in the warsow-data spec. Don't include the folder +or the symlinks there. Also do not ship the folder %gamelibdir/basewsw +in the main warsow package (it's just empty folder as far as I can +tell). Instead just ship a symlink to %{_datadir}/warsow/basewsw as +%gamelibdir/basesw in the warsow package. In order to not have a broken +symlink I'd also suggest you ship the empty folder +%{_datadir}/warsow/basewsw in the main warsow package too. Then when you +ship your data files in the warsow-data files, the main package will +fine them via the single directory symlink. Nothing more needs done, no +complex individual symlinks. + + + +I'd vote for option b. It should work fine from what I can tell, +although I've not looked super thoroughly so there may be some caveat as +to why this will not work. + +Col + + + +-- + +Colin Guthrie +colin(at)mageia.org +<A HREF="http://colin.guthr.ie/">http://colin.guthr.ie/</A> + +Day Job: + Tribalogic Limited <A HREF="http://www.tribalogic.net/">http://www.tribalogic.net/</A> +Open Source: + Mageia Contributor <A HREF="http://www.mageia.org/">http://www.mageia.org/</A> + PulseAudio Hacker <A HREF="http://www.pulseaudio.org/">http://www.pulseaudio.org/</A> + Trac Hacker <A HREF="http://trac.edgewall.org/">http://trac.edgewall.org/</A> +</PRE> + + + + + + + + + + + +<!--endarticle--> + <HR> + <P><UL> + <!--threads--> + <LI>Previous message: <A HREF="021275.html">[Mageia-dev] Help with package +</A></li> + <LI>Next message: <A HREF="021134.html">[Mageia-dev] [338616] Use official tarball +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#21293">[ date ]</a> + <a href="thread.html#21293">[ thread ]</a> + <a href="subject.html#21293">[ subject ]</a> + <a href="author.html#21293">[ author ]</a> + </LI> + </UL> + +<hr> +<a href="https://www.mageia.org/mailman/listinfo/mageia-dev">More information about the Mageia-dev +mailing list</a><br> +</body></html> |