another_commander wrote:tinker wrote:...and Arrch Linux devs seem to be of the opinion that it is a problem for Oolite to solve, not for them to require obsolete libraries.
I will have to take exception to that. Speaking for myself only, I definitely don't see this as a problem and nothing needs resolving. Oolite gets distributed with a set of libraries that have been extensively tested and are known to be working and, as I don't have all the time in the world to dedicate to development, I'd rather use whatever little of it there is to work on the game itself, rather than on the libraries that support it. At least doing it this way I know that when a bug pops up it's because I did something wrong in the game's code and not because the latest version of libpng or whatever other library may have a subtle problem somewhere. Rolling releases may be nice, but they do have disadvantages too and that's probably the biggest one of them.
This is my personal opinion only of course, but I think that doing it this way has served us quite well up to this point.
copied from
https://bb.oolite.space/viewtopic.php?f= ... 90#p224868
Afaict tinker expresses his own opinion there.
He might have based it on
archlinux bug #41428 .
However, Scimmia is just 1 of the arch developers, and not the archlinux oolite maintainer.
another_commander wrote:
Oolite gets distributed with a set of libraries that have been extensively tested and are known to be working
I've looked at the oolite 1.80 source package, especially the libpng14 stuff and found this :
Code: Select all
$ldd ~/Documents/WIP/oolite/oolite-source-1.80/deps/Linux-deps/x86_64/lib/libpng14.so.14
linux-vdso.so.1 (0x00007fff5dbfe000)
libz.so.1 => /usr/lib/libz.so.1 (0x00007f219fb97000)
libm.so.6 => /usr/lib/libm.so.6 (0x00007f219f893000)
libc.so.6 => /usr/lib/libc.so.6 (0x00007f219f4e5000)
/usr/lib64/ld-linux-x86-64.so.2 (0x00007f219ffd2000)
$
so that library should work on archlinux.
However, arch uses 'make -f Makefile release' to build oolite.
This Makefile doesn't seem to do anything with the oolite supplied libraries.
--------------------------------------------------
The distribution-neutral installer using autopackage : it has NO support for pacman (archlinux package manager).
I've downloaded the linux 64-bit installer and ran it like this :
./oolite-1.80.linux-x86_64.run --noexec --target oolite-test
That allows me to check the setup script used by oolite.
It does appear to have a non-interactive option, but to be useful for an archlinux PKGBUILD we need to be able to configure several things.
example :
STARTUP_SCRIPTS_PATH_SYSTEMWIDE="/usr/local/bin"
On archlinux , /usr/local/ is NEVER used by our package manager.
---------------------------------
Now let's look at things from the perspective of an archlinux oolite package maintainer :
1. oolite requires minimal adjustment to build from source
2. oolite build this way runs fine
3. png problems in oxp can be solved by the user manually, no problem for arch users.
4. oolite 1.80 introduced oxz . for oxz files there's no known way to correct the png problems AFTER creation.
5. oolite devs introduced the problem, they should be the ones to solve it.
-------------------------------------------------
I see the following options to solve the problem :
- afaik pngs converted as described in first post work flawlessly in older libpng versions
oxp / oxz creators could perform the necessary conversions
- archlinux builds oolite against libpng14
Arch has a strict policy of 1 library - 1 version, and there are very few exceptions made to that policy.
it will never be done to accomodate 1 program.
The only way this could be done would be if oolite was removed from official repos to unsupported / AUR.
Maintenance of the package would then have to be done by a volunteer archlinux user of unknown competence.
The threshold to install the package would be a lot higher then now.
-
adjust oolite autopackage setup script to be useful inside an archlinux pkgbuild.
-
add an archlinux template to the Makefile that will build oolite using the included libraries
What option does oolite dev team think is the best ?
Note :
i maintain several unofficial AUR packages, and have been maintainer of the oolite aur package for several years before it was moved to community.
