From 1be510f9529cb082f802408b472a77d074b394c0 Mon Sep 17 00:00:00 2001 From: Nicolas Vigier Date: Sun, 14 Apr 2013 13:46:12 +0000 Subject: Add zarb MLs html archives --- zarb-ml/mageia-dev/2013-January/021275.html | 175 ++++++++++++++++++++++++++++ 1 file changed, 175 insertions(+) create mode 100644 zarb-ml/mageia-dev/2013-January/021275.html (limited to 'zarb-ml/mageia-dev/2013-January/021275.html') diff --git a/zarb-ml/mageia-dev/2013-January/021275.html b/zarb-ml/mageia-dev/2013-January/021275.html new file mode 100644 index 000000000..f1bdee111 --- /dev/null +++ b/zarb-ml/mageia-dev/2013-January/021275.html @@ -0,0 +1,175 @@ + + + + [Mageia-dev] Help with package + + + + + + + + + +

[Mageia-dev] Help with package

+ Juan Luis Baptiste + juancho at mageia.org +
+ Mon Jan 7 20:32:13 CET 2013 +

+
+ +
Hi Colin,
+
+On Mon, Jan 7, 2013 at 5:53 AM, Colin Guthrie <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.
+
+
+> 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.
+
+
+>
+> 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
+
+%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.
+
+
+
+>
+> Also your fdupes command seems to do nothing other than display
+> duplicate information, not actually resolve anything. So I'd just remove
+> it or add appropriate arguments to do hardlinking as needed. Unless this
+> package has a particular problem with duplicated data, then I'd just
+> kill it off completely.
+>
+
+I'll check this too.
+
+
+>
+> Hope that gives you some hints.
+>
+>
+Thanks for the comments.
+
+-- 
+Juancho
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: </pipermail/mageia-dev/attachments/20130107/41fc6945/attachment.html>
+
+ + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ -- cgit v1.2.1