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

Re: rman (PolyglotMan) + TkMan are now under the Artistic License.

On Wed, Aug 09, 2000 at 05:22:10PM +0900, Ryuichi Arafune wrote:
> B.R.> Okay, well, there's a few things I need to learn:
> B.R.> 1) Is XFree86 the place where continuing work on the DPS library is going
> B.R.> to continue to happen?
> Yes, may be.
> B.R.> 2) Is the DPS library in dpsclient a separate implementation?  The DPS
> B.R.> library in XFree86 is copyrighted by Adobe, but is under a free license.
> I don't know about that.  Does this web page help you? 
> 	http://dps.sourceforge.net/
> The files are in dpsclient but not in your package. (except under
> /usr/share/doc/)
> /usr/bin/makepsres
> /usr/bin/pswrap

These are in xutils, a new package.

> /usr/lib/libdps.so.0.0.1
> /usr/lib/libdpstk.so.0.0.1
> /usr/lib/libpsres.so.0.0.1
> /usr/lib/libdps.so.0
> /usr/lib/libdpstk.so.0
> /usr/lib/libpsres.so.0

I have all of these, except with higher sonames.

> B.R.> 5) I get the feeling that programs written using the dpsclient library will
> B.R.> not be able to be simply recompiled against libdps-dev.  If that is the
> B.R.> case we will need to continue to provide the old dpsclient package during
> B.R.> the transition.
> I think this is good idea.  
> I think XFree86-4.0 is not stable as 3.3.6.  So the transition does
> not go smoothly. (  At least, I want to use 3.3.6 for the present. )
> I will maintain dpclient package until almost users use XFree86-4.  

Well, the stability of the XFree86 4.x servers is one thing, and the
stability of libdps is another.

Stephen R. Gore, who is taking over maintenance of XFree86 3.x from me, is
working on new 3.x packages for woody to work in conjuction with my 4.x
packages.  These XFree86 3.x packages will ship only X servers who possess
hardware support that 4.x doesn't yet.

XFree86 3.x may also provide the xlib6 and xlib6-altdev packages, if Ben
Collins's proposal to drop libc5 support from woody doesn't go through.

> B.R.> 6) Are there any files in my libdps* packages with the same names as files
> B.R.> in your dpsclient* packages?  If so, I need to Replace: your packages as
> B.R.> well.
> Yes. Please put "Replace: dpsclient" in your control file.

Okay, how does this sound?

libdps1 will Replaces: dpsclient

libdps-dev will Replaces: dpsclient-dev
                Conflicts: dpsclient-dev

xutils will Replace: dpsclient

I think that should be all that is necessary.  If you like, for woody you
could remove makepsres and pswrap from dpsclient (since they will be
available in xutils anyway), and I will version the Replaces: on xutils.
This way people could have both dpsclient (libdps0) and libdps1 installed
at the same time and support packages compiled against either one.

Of course, libdps-dev will have to conflict with dpsclient-dev anyway
because you can have only one set of these include files installed at a

Does all this sound reasonable?

I'll check out dps.sourceforge.net and see what's going on with
development, and whether XFree86 has absorbed this project or whether they
just ship this stuff for convenience.  If the latter, I may drop my planned
libdps* packages.

G. Branden Robinson            |    The errors of great men are venerable
Debian GNU/Linux               |    because they are more fruitful than the
branden@deadbeast.net          |    truths of little men.
http://deadbeast.net/~branden/ |    -- Friedrich Nietzsche

Attachment: pgpYKQrW4348V.pgp
Description: PGP signature

Reply to: