Re: Pre-Depends changed for dpkg on GNU/kFreeBSD
On Sat, 2014-10-04 at 23:59:25 +0200, Guillem Jover wrote:
> On Fri, 2014-10-03 at 04:45:13 +0200, Guillem Jover wrote:
> > On Thu, 2014-10-02 at 22:03:37 +0100, Steven Chamberlain wrote:
> > > No problem. Does that mean you'd happily revert to using linprocfs?
> >
> > If there's no better option, yes. Right now I'm thinking to merge
> > the attached patch for 1.17.14 as a hotfix, and then switch to a pure
> > sysctl(2) implementation for 1.17.15, so that we can get rid of the
> > libkvm dependency. Otherwise revert to linprocfs. Does that sound good?
>
> Something else I just realized now is that libkvm pulls in libbsd and
> libfreebsd-glue into the pseudo-essential set on GNU/kFreeBSD, which
> makes the situation a bit worse. So as stated above I'll be switching
> to sysctl(2) later on, but I'm open to a revert if this is deemed
> problematic too. Thanks for input Steven!
s-s-d only needs struct kinfo_proc (either when using libkvm or
sysctl(3)), so I just did a bit of digging and it seems the last time
ABI was broken for that struct was around 2005. It seems since then
upstream has gotten lots better, and added unused space to be claimed
whenever the need arises. I'd expect them to switch to a new MIB in
case they break ABI for that struct again, as they did with kinfo_file.
I'm thinking that I could also make the code fallback to linprocfs at
run-time in case the ki_structsize member differs from the size known
at build time, which would give an additional safe guard, in case the
above does not hold true.
On Sun, 2014-10-05 at 08:54:41 +0200, Sven Joachim wrote:
> On 2014-10-04 23:59 +0200, Guillem Jover wrote:
>
> > Something else I just realized now is that libkvm pulls in libbsd and
> > libfreebsd-glue into the pseudo-essential set on GNU/kFreeBSD, which
> > makes the situation a bit worse.
>
> Both libbsd and libfreebsd-glue are already pulled in by freebsd-utils.
Ah, right, thanks Sven for looking it up, still given that libkvm can
be easily avoided, I think it's fine to get rid of it from the
pseudo-essential set.
Thanks,
Guillem
Reply to: