DragonFly users List (threaded) for 2009-05
DragonFly BSD
DragonFly users List (threaded) for 2009-05
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: pkg_dry on DragonFlyBSD

From: "Steve O'Hara-Smith" <steve@xxxxxxxxxx>
Date: Sat, 9 May 2009 14:01:13 +0100

On Sat, 9 May 2009 10:08:16 +0300
Hasso Tepper <hasso@estpak.ee> wrote:

> Steve O'Hara-Smith wrote:
> > Like kqemu it's a kernel module with only one client, kqemu is only
> > used by qemu and the DRM kernel module is only used by the Xorg server.
> > They are both bridge modules with one end of their interfaces
> > determined by the client (and thus not under the control of the
> > DragonFly project) and one end determined by the kernel interfaces of
> > DragonFly. Both of these interfaces are subject to change over time.
> There is many things not under control of the DragonFly project.

	Indeed there are, but few of them are kernel related and subject to
change at the whim of another project.

	My main point though was that kqemu and drm are similar in this

> > There may well come a time for either of these where there are two
> > incompatible versions extant supporting two actively used versions of
> > their client (think around a major version bump).
> This situation just isn't acceptable. It isn't acceptable even for Linux 
> (as DRM "upstream").

	Acceptable or not, I don't see any way of preventing it from

> > It would be much easier to maintain multiple active versions in the 
> > pkgsrc framework than in the kernel source tree.
> Have you tried it? How do you manage kernel interface changes? It isn't 
> hypothetical, DRM depends closely on many things in kernel (agp(4), 
> pci(4)).

	I see two possible ways - options or multiple packages.

	I agree that handling the kernel interface changes is easier when
the code is in the DragonFly tree. OTOH handling API changes required by
the client code is hard within the tree, it would pretty much require two

> How do you manage having pkgsrc package files outside of pkgsrc 
> prefix?

	Er wasn't the suggestion upthread to have pkgsrc/dfly or
thereabouts, ie. within the pkgsrc prefix but presumably not in the pkgsrc

Steve O'Hara-Smith                          |   Directable Mirror Arrays
C:>WIN                                      | A better way to focus the sun
The computer obeys and wins.                |    licences available see
You lose and Bill collects.                 |    http://www.sohara.org/

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