Jaeger: systemd - and #osc2010

Posted Oct 9, 2010 16:07 UTC (Sat) by MrWim (subscriber, #47432)
In reply to: Jaeger: systemd - and #osc2010 by tzafrir
Parent article: Jaeger: systemd - and #osc2010

SystemD manages its dependencies by the config files describing the services a program provides rather than listing the other programs it depends on. This means that in theory these config files are less dependant on the environment in which they are installed so should be more portable between distributions.

That's the theory, but I can't answer how much it is the case in practice.

Jaeger: systemd - and #osc2010

Posted Oct 9, 2010 16:38 UTC (Sat) by drag (guest, #31333) [Link] (12 responses)

Yeah. The Systemd opens the Unix sockets on behalf of the services it supports and when something attaches to the socket then Systemd launches the service. A bit like the super internet daemon, but with Unix sockets instead of network ones.

It's not just the configuration files, though. The developer has to take systemd into account and provide support for it in their daemon.

Unfortunately portability probably won't be realized either because distros cannot work together to agree to direction/file locations and naming conventions which will require every developer that is attempting to work with multiple distros be forced to do the distro's work for them and take into account the little useless variations in each system they want to support. Every developer; every application.

Portability

Posted Oct 9, 2010 22:16 UTC (Sat) by dwheeler (guest, #1216) [Link] (11 responses)

In the short term there will definitely be portability issues. In the long term there might be, but they need not be significant. The Filesystem Hierarchy Standard helps, and implementations that currently implement PREFIX and DESTDIR with a "make install" script can make such differences a non-problem.

Portability

Posted Oct 10, 2010 0:58 UTC (Sun) by nix (subscriber, #2304) [Link] (10 responses)

Yes, but 'prefix' is lowercase.

(claiming one pedant point, since I'm certain you already knew this!)

Standards for releasing software

Posted Oct 10, 2010 1:57 UTC (Sun) by dwheeler (guest, #1216) [Link] (9 responses)

Yes, it's "prefix" not "PREFIX". You get one point :-). In my defense, I've just been trying to package a program which doesn't follow the usual conventions (making it a pain), and it uses PREFIX instead of "prefix".

Which gives me a reason to pitch my short essay, "Releasing Free/Libre/Open Source Software (FLOSS) for Source Installation". This tries to convince people to follow the usual conventions, and points to stuff like GNU coding standards (especially the release process), the Software Release Practice HOWTO, and the Filesystem Hierarchy Standard (FHS).

If people would just follow the usual standards and conventions, many portability problems would go away.

Standards for releasing software

Posted Oct 10, 2010 2:00 UTC (Sun) by drag (guest, #31333) [Link]

Very cool.

Standards for releasing software

Posted Oct 10, 2010 5:27 UTC (Sun) by pabs (subscriber, #43278) [Link]

Very nice article, thanks.

I added a link to your article from Debian's UpstreamGuide wiki page. I note you link to the old name (GettingPackaged) in the article, could you amend that please?

Standards for releasing software

Posted Oct 10, 2010 15:36 UTC (Sun) by aleXXX (subscriber, #2742) [Link] (2 responses)

A bit autotools-centric for my taste, e.g. cmake is only barely mentioned.

Alex

Not autotools-centric

Posted Oct 11, 2010 1:35 UTC (Mon) by dwheeler (guest, #1216) [Link] (1 responses)

I don't understand why you say, "autotools-centric for my taste, e.g. cmake is only barely mentioned." Autotools is only mentioned once, and only after cmake. This article isn't about either autotools or cmake, and isn't really focused on either. Instead, it's about the interface you should provide to end-users. Autotools and cmake (or other tools) can be used to implement that interface, but they are just ways to get there.

Not autotools-centric

Posted Oct 11, 2010 10:16 UTC (Mon) by stumbles (guest, #8796) [Link]

I don't care if it does lean towards autotools at the cost of cmake. Its still an excellent overview of how to properly package code. There is nothing (well there is) more annoying than encountering a half-baked configure or Makefile script.

Standards for releasing software

Posted Oct 11, 2010 22:26 UTC (Mon) by man_ls (guest, #15091) [Link] (3 responses)

Very nice, thanks. I miss a similar standard for Python -- library management is a mess, setup.py sucks a bit, and internationalization has to be done manually.

Standards for releasing software

Posted Oct 12, 2010 14:09 UTC (Tue) by mpr22 (subscriber, #60784) [Link] (2 responses)

If you didn't think about i18n from day one when writing your program, it's always going to involve a lot of unpleasant drudgework to add it. Only static (or tersely technical, such that it doesn't matter if it looks like "computerspeak") communication to the user can reasonably be localized via the likes of gettext(); for everything else, you need code.

Standards for releasing software

Posted Oct 12, 2010 14:57 UTC (Tue) by man_ls (guest, #15091) [Link] (1 responses)

Sorry, I didn't explain myself. The actual process was more or less painless; using gettext is not so hard. But installing the translation files was a real pain -- there is no actual mechanism in Python. You have to find the target directory using gettext.bindtextdomain('yourpackage') and then copy the .mo files manually, keeping the right directory structure. Not pretty.

Standards for releasing software

Posted Oct 14, 2010 9:40 UTC (Thu) by mpr22 (subscriber, #60784) [Link]

OK, that makes sense. (Eww.)