1 (edited by i.gnatenko.brain 2013-07-04 08:30:52)

Topic: [idea] [patch] systemd unit improve and delete external libraries

Hi all!
I think this good idea.
We can add new configure option for create systemd service. We use pnglite.h from teeworlds and this wrong.
In my blogpost I review of my systemd unit and propose patch for remove external libraries.
http://ignatenkobrain.blogspot.ru/2013/ … erver.html

2

Re: [idea] [patch] systemd unit improve and delete external libraries

Could you further explain, why you want to remove the external libs?
As I am pretty sure that they are needed, e.g for windows

3

Re: [idea] [patch] systemd unit improve and delete external libraries

Well well well, thanks for the proposition, but really:

We use pnglite.h from teeworlds and this wrong.

I don't see any problem with that, do you?

Not Luck, Just Magic.

4

Re: [idea] [patch] systemd unit improve and delete external libraries

Dune wrote:

Well well well, thanks for the proposition, but really:

We use pnglite.h from teeworlds and this wrong.

I don't see any problem with that, do you?

np. ah. I see. for Windows... smile
External lib question expried, but systemd daemon is open smile

5

Re: [idea] [patch] systemd unit improve and delete external libraries

I'd also like to not ship libraries with Teeworlds, especially the SDL binaries, but it just takes care of a huge annoyance (especially on Windows).

As for a systemd .service: We don't have any kind of startup scripts so far, but adding some wouldn't hurt I guess. On the other hand, .service files are trivial to create; compared to init-style scripts at least.

6

Re: [idea] [patch] systemd unit improve and delete external libraries

m!nus wrote:

I'd also like to not ship libraries with Teeworlds, especially the SDL binaries, but it just takes care of a huge annoyance (especially on Windows).

As for a systemd .service: We don't have any kind of startup scripts so far, but adding some wouldn't hurt I guess. On the other hand, .service files are trivial to create; compared to init-style scripts at least.

I already improved in fedora service file. I think init files no needed as majority of distribs using systemd.

7

Re: [idea] [patch] systemd unit improve and delete external libraries

i.gnatenko.brain wrote:

I think init files no needed as majority of distribs using systemd.

That's not true, the most used distributions (in non-enterprise), Debian and Ubuntu, do not have Systemd. Whereas both have packages  for Systemd they are experimental and the likelyhood of Systemd being adopted as default on Debian is rather low.
Of course init-scripts are not needed, but neither are service files. It worked fine without those for the past six years.

8

Re: [idea] [patch] systemd unit improve and delete external libraries

m!nus wrote:
i.gnatenko.brain wrote:

I think init files no needed as majority of distribs using systemd.

That's not true, the most used distributions (in non-enterprise), Debian and Ubuntu, do not have Systemd. Whereas both have packages  for Systemd they are experimental and the likelyhood of Systemd being adopted as default on Debian is rather low.
Of course init-scripts are not needed, but neither are service files. It worked fine without those for the past six years.

If you need I can write initscript (download from my debian server)

9 (edited by ghost 2013-07-09 09:15:00)

Re: [idea] [patch] systemd unit improve and delete external libraries

One big problem I encountered with init scripts for teeworlds is, that they are not very flexible. Many people are running several teeworlds servers on their server and which servers are online often changes. What I want to say is this: If you use an init script, you want to write/configure it once and then just use it, as it is. This is not applicable for teeworlds, because often you find yourself in the situation of creating a new server or removing one etc. It's very inconvenient to edit the init script everytime.

Another problem is, that teeworlds is not that stable and crashes sometimes, so you probably want an autorestart feature for teewolrds.

For both of those reasons, I am currently using supervisor to start/stop/control my teeworlds servers.

I agree with you about the use of external libraries, they should be removed. In binary releases, we should keep them in however (SDL.dll etc.)

@m!nus: In what way is using our pnglite/zlib better/easier/whatever than using system one? I mean, we have to install sdl, too, to compile, why not those libraries, too?

10

Re: [idea] [patch] systemd unit improve and delete external libraries

ghost wrote:

In what way is using our pnglite/zlib better/easier/whatever than using system one? I mean, we have to install sdl, too, to compile, why not those libraries, too?

Using the system one is better, on Windows it's extra work though. This could of course be solved by having scripts do the downloading and compiling; or just let the user (which in this case is a developer anyway) do that.

11

Re: [idea] [patch] systemd unit improve and delete external libraries

ghost wrote:

One big problem I encountered with init scripts for teeworlds is, that they are not very flexible. Many people are running several teeworlds servers on their server and which servers are online often changes. What I want to say is this: If you use an init script, you want to write/configure it once and then just use it, as it is. This is not applicable for teeworlds, because often you find yourself in the situation of creating a new server or removing one etc. It's very inconvenient to edit the init script everytime.

This problem solved by me in systemd unit (multiple configuration). In first message I showed this.

ghost wrote:

Another problem is, that teeworlds is not that stable and crashes sometimes, so you probably want an autorestart feature for teewolrds.

Bad idea because we should fix problems with stable, but not solve this by.

m!nus wrote:

Using the system one is better, on Windows it's extra work though. This could of course be solved by having scripts do the downloading and compiling; or just let the user (which in this case is a developer anyway) do that.

I think additional scripts is better idea.