Re: [Sks-devel] Whats last version of SKS Server?

[John Clizbe]

Jens Leinenbach wrote:
> Hi Edson,
> 
> Just to give a substantive answer:

There is NO SKS version 1.1.4. There is an offshoot binary-only build for
AMD64 by a couple users with a prematurely bumped version number. The
closest thing to a real 1.1.4 is 1.1.3-1e8897a5f5f4.

> SKS versions 1.1.1 to 1.1.3 searches and puts really everything in one
> "base" directory which is incompatible for all Linux distributions that
> insist in properly set directories.

"Properly" is a value judgment/opinion.

> If you have your logfiles in /var/log/sks, then you already use a
> patched SKS version as the original source code of version 1.1.3 just says:
> let fname = (Filename.concat !Settings.basedir extension) ^ ".log" in

That would be Debian or Ubuntu, and any others based on that work. I have not
seen a FHS patch from the RPM based distributions.

> As there is no Linux distribution that can compile SKS without making a
> lot of changes first to make it somehow compatible with all directories,
> most them prefer to use an old patched version 1.1.1.
> And if you use the Ubuntu or Debian version of SKS right now, you still
> get a patched SKS version 1.1.1 with a hard coded empty ("") base
> directory. All other directories are added hard coded afterwards. BTW:
> This solution breaks immediately if you use the command line option to
> set the base directory of SKS somewhere else.

"no" is a rather large and presumptuous conclusion. Had you said "FHS-based"
Linux distribution, I'd agree with you. You cannot apply the behavior of one
set of distributions to the whole.  An hg pull of sks builds fine on Slackware
Linux with *only* the stated Ocaml & Berkeley DB prerequisites.
I would venture any of Linux not shackled to the FHS can also.

Ditto for other Unices: Mac OS X, and Solaris I've verified

The Debian solution breaking "immediately if you use the command line option
to set the base directory of SKS somewhere else" should be a Debian bug.

> "The patch was a whole lot of changes at once." as John Clizbe wrote -
> all those changes were needed to fix only this one issue.
> With the patch you can find in the archive of this list, everyone is
> able to compile it for all Linux distributions properly without the need
> to patch a lot of files yourself first.
> With this big patch, I changed the version number to 1.1.4, too.

I'll point out ONCE MORE, the original argument here was with the Debian
maintainers not being fast enough with a new release. I'm working on the NEXT
release of SKS, the "REAL" 1.1.4. Patches submitted /AFTER/ a release go in
the next release.

I guess I was dragged into this sordid mess because I didn't immediately apply
the patches I _had_ been furnished. The other patches Sebastian mentions were
not and have not been submitted for mainline inclusion. In that sense, they
are forking and should change the name and create their own project.

Sebastian seems intent on keeping up the antagonism and using a source-less
binary-only single CPU-architecture distribution model. I guess the project
model they are using is anarchy.

> In the meantime, I kept the version "1.1.4" but upgraded from Cryptokit
> 1.0 to Cryptokit 1.5, use BDB 5.1 and added some minor bug fixes. I
> compiled it with native-code compilation. Sebastian and I use it for our
> servers and it is quite fast and very stable for us.

Yes, and the cryptokit-1.5p you sent me still required the OASIS build system
and findlib. THAT is why I didn't use it, it added additional build
dependencies. I said I'd upgrade from 1.3 to 1.5 if it could be done with a
trivial amount of work and no headaches for users building their own binaries.
That last part doesn't seem to be a concern of Sebastian and you, that it
works for everyone. My devel repo is now at cryptokit-1.5, minus the cryptokit
dependencies of the OASIS build system and its dependencies.