On Tue, Jun 26, 2018 at 11:25:51AM +0300, Leonid Bobrov wrote: > On Tue, Jun 26, 2018 at 02:17:14AM +0300, Leonid Bobrov wrote: > > On Mon, Jun 25, 2018 at 10:04:24PM +0200, Landry Breuil wrote: > > > On Mon, Jun 25, 2018 at 05:21:48PM +0300, Leonid Bobrov wrote: > > > > Hi! > > > > > > > > This is engine's bugfix release, minetest_game didn't change. > > > > > > > > I hope this time I won't have to send more diffs: > > > > > > Thanks, i've commited your diff. If you want to take maintainership or > > > do more work on this port there's some room for improvement: > > > - subpackage the server in a distinct package > > > > In that case to avoid conflicts I need to package minetest_game too, > > also is it a good idea to make minetest_game optional dependency for > > both client and server like FreeBSD ports already did it? > > (actually they made client/server/both dependencies of minetest_game, > > I can't do that because unlike them I'll separate game and server) > > > > Also I need to check if client and server as separate packages have > > conflicts in PLIST. > > > > > - fix the system libgmp detection in cmake/findGMP.cmake > > > - the port doesnt respect the default cflags, which are -O2 -pipe. At > > > least they stopped doing the crazy -O3 -funroll-loops dance.. > > > > > > Landry > > > > > > > Ok, I've divided this package into two subpackages and created > minetest_game package to avoid conflicts. But these two subpackages > have conflicting PLIST, they share the same files (yes, I know > update-plist can't handle multy packages, I handled that manually). > > I think it is better to leave everything in one port, there is no > opportunity to divide it into two or three ports, it makes maintainance > harder in cost to build one package twice faster, it appears Minetest > doesn't support multipackaging installation. > > If you think multy packaging is necessary, I can do the same thing > Arch Linux community does: remove everything from server's plist that > conflicts with client's plist, in that case server will have client > as optional dependency, is that fine? Minetest server will have only > two files installed: > @bin bin/minetestserver > @man man/man6/minetestserver.6
I dont think multipackaging is *necessary*, it might just be convenient for ppl that want to just run the server, without having all the dependencies the client has. It would also split the dependencies, but i dont know if it is worth the effort. But converting a port to multipackages requires some knowledge of the portstree :)
