[Mageia-dev] Help with package

Tue Jan 8 10:49:43 CET 2013

[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:
+> Hi Colin,
+> 
+> On Mon, Jan 7, 2013 at 5:53 AM, Colin Guthrie <mageia at colin.guthr.ie
+> <mailto:mageia at colin.guthr.ie>> wrote:
+> 
+>     > Well, it worked on x86_64, but  on i586 the symlinks are created under
+>     > /usr/lib64/games/warsow/basewsw instead of
+>     /usr/lib/games/warsow/basewsw
+>     > but I don't understand why, it seems that for some reason, the
+>     > %{_libdir} macro is expanding to /usr/lib64 on the BS. This is the
+>     spec
+>     > if someone wants to take a look:
+>     >
+>     >
+>     http://svnweb.mageia.org/packages/cauldron/warsow-data/current/SPECS/warsow-data.spec?revision=338836&view=markup
+> 
+>     %_libdir expands to the given architecture's libdir. On i586 it's
+>     /usr/lib, on x86_64 it's /usr/lib64.
+> 
+> 
+> I know, that's why it's strange to me why when the package is built on
+> the BS the links end up on /usr/lib64 on the i586 package.
+
+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.
+
+>     Looking at the spec, I think you're doing it a bit wrong.
+> 
+>     It's in the %post for a start which is wrong. It should be done as part
+>     of package build, not install. Doing it during install will mean the
+>     files are not "owned" by the package so users cannot tell where they
+>     come from.
+> 
+> 
+> Well, that was just a suggestion from someone on this thread and it
+> looked to me like the right place too. On this particular case what I'm
+> doing here is not installing some files but creating some symlinks that
+> the other warsow package needs. 
+
+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.
+
+
+>     Also as you use %_libdir, your package cannot be noarch.
+> 
+> 
+> The "warsow-data" package contains the data files of the game which are
+> arch independent. The "warsow" package contains all the binaries and
+> libs, but to be able to run the game, the binary expects to find the
+> data files on the same directory where the libs are, if not then the
+> angelscript module will fail loading. So, what I'm trying to accomplish
+> is that when warsow-data is installed, symlinks of the files in the data
+> directory (/usr/share/warsow/basewsw/*) are created on
+> /usr/lib{64}/games/warsow/basewsw/. It works on x86_64 but on i586 is
+> creating the links on lib64 instead of lib and I don't get why, you saw
+> the code in the spec, I'm not hardcoding any path on it:
+> 
+> 
+> %define gamelibdir%{_libdir}/games/warsow
+
+                    ^^^^^^^^^^
+
+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.
+
+> %post
+> #Add symbolic links of the contents of basewsw to the directory were the
+> #package warsow install the libs, if not then angelscript fails to load.
+> for i in %{_datadir}/warsow/basewsw/*;
+> do
+>   file=`basename $i`
+>   ln -sf $i  %{gamelibdir}/basewsw/$file
+> done
+> 
+> %postun
+> rm -rf %{gamelibdir}/basewsw
+>  
+> 
+> 
+>     If you want to use /usr/lib all the time then do so (if that's what the
+>     game binary expects) via %{_prefix}/lib not via %_libdir.
+> 
+> 
+> 
+> That's not the case, as explained before, the symlinks have to be
+> created at /usr/lib for i586 and at /usr/lib64 for x86_64, but on i586
+> for some reason isn't doing it.
+
+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
+http://colin.guthr.ie/
+
+Day Job:
+  Tribalogic Limited http://www.tribalogic.net/
+Open Source:
+  Mageia Contributor http://www.mageia.org/
+  PulseAudio Hacker http://www.pulseaudio.org/
+  Trac Hacker http://trac.edgewall.org/
+