(This message may arrive as a duplicate, because my ISP sucks and
appears to have lost the first one. Sorry about the noise if it
miraculously recovers it.)
Hello everyone,
Christmas has arrived!
The December 2014 skarnet.org release is ready. (For once, I held to the
deadline I had set for myself. Yes, this is an accomplishment.)
There are not many functional changes - every package does, on the outside,
fairly - or exactly - the same thing as it did before. But this release is
still a major milestone, because it sets the foundation for future work:
- The build system of skarnet.org packages is now configure/make/make install,
which is easier to understand and use for most people. I hope this will
encourage more users to give my software a try, and more distributions to
package it. If you've always hated my previous build system, rejoice: it's
gone for good. If you've always hated autotools, don't worry: I have not
switched to autotools, and never will.
Slashpackage installations are still supported, even if they are not the
default anymore. Slashpackage-enabled installations will call binaries
with absolute paths (unversioned for inter-package dependencies and versioned
for intra-package dependencies), whereas not-slashpackage-enabled ones will
call binaries by name and rely on the PATH environment variable, even for
intra-package dependencies.
- The set of sysdeps tested by the skalibs configuration process has been
entirely changed and modernized. Old tests have been removed, new ones have
been added as needed to address portability issues of 2014 instead of ones
of 2002. Cross-compilation is easier than ever.
- Packages now put their header files in their own subdirectory of
/usr/include, to avoid cluttering the header namespace. For instance, the
skalibs headers' main entry point is <skalibs/skalibs.h>.
By default, packages also put their static library files in their own
subdirectory of /usr/lib. This can be a pain for linking, but it is
cleaner, and the ./configure default does the appropriate magic to make
it just work.
- Packages should now compile and run as-is on Linux i386/x86_64/ARM,
FreeBSD, OpenBSD, NetBSD, Solaris and MacOS X. Cross-platform compatibility
should be a formality, but it's really not - some systems really go out of
their way to interpret standards in the most demented way possible (I'm
looking at you, FreeBSD) and ensuring good, reproducible behaviour on
supposedly POSIX OSes is a lot more work than it appears; it is today as it was
15 years ago, if not worse. Nevertheless, I now have access to a few systems
for testing, and can make sure everything works before releasing. A big
thank you to Zoltán Árpádffy for
http://polarhome.com/ .
- Packages are now tracked by git. Every package has its publicly accessible
repository on git.skarnet.org. I haven't yet set up a web interface, because
I can't figure out how cgit is supposed to compile, but I may get to it soon
if there's demand.
(Disclaimer: I curse a lot in commit logs. Do not follow day-to-day
development if you're offended by profanity. Definitely do not follow it if
you're a BSD kernel/libc developer.)
A word of warning: skarnet.org packages need at least GNU make 4.0 to compile
now.
Some distributions see fit to only package GNU make 3.82, which is four years
old, or even GNU make 3.81, which is eight years old. GNU make 4.0 is more
than one year old (and 4.1 has been released two months ago); I figured
one year should be enough for people to update their development tools.
If you don't have 4.0+, or do not have GNU make at all, it's not a sin:
BSD users should be pitied and helped, not scorned. Just know that GNU make
is a breeze to install manually: it's incredibly clean, compact, and easy
to compile, for a GNU package. I definitely had a very good surprise there.
On to the details!
skalibs-2.0.0.0
---------------
* Lots and lots of changes, most of them internal, some of them not so much.
Overall, skalibs has been simplified. I think.
* Only one big library now ("-lskarnet") instead of several small ones. This
makes it easier for shared libraries junkies, and simplifies compilation
altogether.
* It's a major number change. No compatibility ensured with previous versions;
expect serious nasal demons if you don't properly port stuff to skalibs 2.
If you have software depending on skalibs and want to upgrade, please ask for
help on the list. Most of the upgrade is straightforward or scriptable, but
some parts will be tricky.
* For once, I'm glad to have slacked on documentation. I would have had to
rewrite a significant part of it. I did rewrite a part of it anyway. And no,
I didn't complete it. Sorry: code is more fun to write than doc. (Unless it's
BSD compatibility code, of course.) I'm totally willing to answer questions
about skalibs interfaces on the list, though, to make up for the ever lacking
documentation.
* The biggest addition is skalibs/unixmessage.h: easy message-passing across
processes. Messages can include file descriptors. skalibs/skaclient.h has been
rewritten around it. s6-svwait is using it. skabus will use it. It works on
decent implementations of the sendmsg() standard... and on braindead ones too.
I'm pretty proud of it, and if you knew the horrors I've been through to make
it work everywhere, you'd be proud too.
http://skarnet.org/software/skalibs/
git://git.skarnet.org/skalibs
execline-2.0.0.0
----------------
* No functional changes. Due to the underlying change in skalibs, some
execline programs may use posix_spawn() instead of fork(), so they may
be marginally more efficient on some systems or have slightly different
error messages. Nothing remarkable.
* Binary location information is available in <execline/config.h>:
EXECLINE_BINPREFIX is the versioned prefix (you should not use that one)
and EXECLINE_EXTBINPREFIX is the unversioned one (which you should use).
This is useful for script generators: to generate an execline script,
you would start with "#!" EXECLINE_EXTBINPREFIX "execlineb". An empty
EXECLINE_EXTBINPREFIX means that there's no guaranteed installation
path, and the programs should be found via the PATH environment variable -
PATH search works in shebang lines too. (Even on BSD. Miracles happen.)
Other packages use the same mechanism for binary location information,
but it's obviously more important for execline.
http://skarnet.org/software/execline/
git://git.skarnet.org/execline
s6-portable-utils-2.0.0.0
-------------------------
* No changes, just a port to skalibs-2.0.0.0.
http://skarnet.org/software/s6-portable-utils/
git://git.skarnet.org/s6-portable-utils
s6-linux-utils-2.0.0.0
----------------------
* No changes, just a port to skalibs-2.0.0.0.
http://skarnet.org/software/s6-linux-utils/
git://git.skarnet.org/s6-linux-utils
s6-2.0.0.0
----------
* Internal changes and cosmetic fixes all over.
* s6-supervise's ./event fifodir is now created private to
s6-supervise's gid instead of public. This prevents trivial DoSsing.
* A readiness notification helper program, s6-notifywhenup, has been
added, as well as support for the 'U' event in s6-svwait. This allows
services running under programs such as s6-[ipc|tcp]server* to benefit
from accurate state tracking.
http://skarnet.org/software/s6/
git://git.skarnet.org/s6
s6-dns-2.0.0.0
----------------------
* Minor fixes in s6dns-engine and skadns.
http://skarnet.org/software/s6-dns/
git://git.skarnet.org/s6-dns
s6-networking-2.0.0.0
----------------------
* Minor fixes all over.
* Serious bugfix in minidentd. Nobody noticed it malfunctioning in
years, not even myself, and that is actually a good thing: the less
people use IDENT, the better.
http://skarnet.org/software/s6-networking/
git://git.skarnet.org/s6-networking
And that's it for today. Please keep sending your bug reports,
feature requests, comments, etc., to the list.
Planned future work
-------------------
This is always subject to changes, suggestions, adjustments.
- Short term:
* a synchronous option for s6-svc: do not return before the command
has taken effect.
* a fd-holding daemon + client library, to add to the s6 toolbox
* network utilities as the need arises. (Currently stuck with an
optic fiber ISP that doesn't understand DHCP leases, so I need to build
a router that actually works.)
- Mid term:
* fd-passing options to s6-[tcp|ipc]server* to take advantage of the
fd-holding daemon (for instance to upgrade s6-networking without service
interruption)
* skabus
* trivial cgroups support for s6 on Linux
* a complete stage 1 init script for Linux systems
- Long term:
* a service dependency manager over s6, using script generators
* a thorough study of the features people find useful in systemd, and
if possible, a sane/Unixish implementation of those features
* communication about that work
* world domination
Merry Christmas, if applicable, and happy New Year, if applicable, to
everyone !
--
Laurent
Received on Mon Dec 22 2014 - 16:36:09 UTC