sks-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Sks-devel] Debian asks package and default paths


From: Hendrik Visage
Subject: Re: [Sks-devel] Debian asks package and default paths
Date: Tue, 23 Jan 2018 18:55:19 +0200

Thanks for the explanation Daniel

> On 23 Jan. 2018, at 18:18 , Daniel Kahn Gillmor <address@hidden> wrote:
> 
> On Tue 2018-01-23 10:51:54 +0100, Alain Wolf wrote:
>> I would try to change desired filepaths in
>> debian/patches/0001-use-debian-fhs.patch
> 
> Hi there--
> 
> I'm one of the current maintainers of the debian package.
> 
> this patch is intended to put sks in compliance with the filesystem
> hierarchy.
> 
> however, i'm not convinced that the patches in the debian package are
> the right thing for debian today, since they basically hardcode a single
> path (and make it difficult to run two instances of sks on the same
> machine, for example).  I'd welcome any proposals people have that:
> 
> a) retain the default filesystem placement to stay in line with the
>    filesystem hierarchy standard (FHS)

Well… FHS makes sense…. up to the point that I’m deploying each service in
it’s own set of mountpoints (ala old-style unix when disks was small, like in 
VMs
today with OS disk separate from the data disks)

> b) enables running multiple keyservers on a given host

That is what base_dir: is suppose to achieve, isn’t it?

> c) people can upgrade their existing installations without too much
>    pain

Yes, that’s the part that always becomes a problem  in special setups...

> d) (optional) can be merged upstream so that we don't carry patches :)
> 
> If i had more time, i'd experiment with dropping the patch completely,
> and setting up a symlink approach in /etc/sks/ but i'm not sure whether
> that would work; or if it works, if it would horrify anyone.

I’d personally rather prefer a configuration file/settings I could modify/tweak
w.r.t. those files/etc., then it’ll be much easier to have multiple SKS 
services on the
same server/VM.

> Anyway, i'm just saying that just because it's this way today, it
> doesn't have to be this way forever.  feedback welcome :)

As it’ll be a recompile/repackage to achieve my goals (other than symlinks all 
over the show)
I’ll have a look as see what I can contribute back.

Attachment: signature.asc
Description: Message signed with OpenPGP


reply via email to

[Prev in Thread] Current Thread [Next in Thread]