A real case.
I think I need a real case to explain the problem with OS distribution
and /opt.
Although I've changed the names of the program and the library, this is
a real case: XFmail and xforms library: I'm not XFmail author, but I've
tryed several times to package it, never beeing able to, because I
wasn't running unstable.
-------------------
I'm the author of the bar-mail program which depends on the foo library.
I want to distribute my program also in .deb format because some of my
users run debian and asked for that. I tryed to do this on a machine
running Debian 1.3, but my program depends on the foo library which is
already a debian package included in the OS.
But this library is in quick development and changes frequently. I keep
my program in-line with these changes, so my latest stable version of
the program always depends on the latest version of the foo library.
But this version of the library is never included in Debian (stable) and
is always in unstable because of the frequent changes. Instead I want to
package bar-mail for the stable debian release, because my users are
running it (and doesn't want to upgrade to unstable).
How can I do that?
I have thought of taking the libfoo latest version from unstable and
recompiling it in a stable machine, and distribute the resulting .deb
from my ftp site. But doing that I have two problems: the version
numbering (I think I should avoid clashes with your official releases)
and the maintenance problems (users could start raising bugs based on my
version to your maintainer. They would be right, because I have only
recompiled his version on a stable machine, but he refuses them because
they doesn't belong to a version released by him, and that he could
test).
I could ask the libfoo.deb maintainer to release a stable version of the
latest library, but he can't upload in stable-updates because policy
forbits this, and not in unstable because there's yet the same version
depending on different things.
I said him to use a different name, but he doesn't think that this is
right to do (he don't want to release several version of the same
package simply on request of external people), and he doesn't want to
bother with all those different version, and he hasn't a stable machine
on which do that.
So I should release both the library and the program as .deb packages
"external" to the OS. Could I put libraries under /usr/lib and programs
under /usr/bin ?
And how to handle conflicts with the library with the same soname that
could become stable later when unstable is realeased and users upgrade?
Why do you pretend to assert that the library is part of the OS if you
don't want to include it in your stable release (your policy on this is
OK, but its effect is not)?
Woudn't be better to leave the library out of the OS so maintainer
couldn't be oblidged by the policy to not realease a stable version (and
distribute from a public ftp site like sunsite)?
------------------
this could be a message coming from an author wishing to see his work
running on debian. As I said it's not pure fantasy, as I had this exact
problem trying to package XFmail.
In the realty XFmail's author said that he would not release a debian
package, and I didn't like that.
Also the Mnemonic project is in a similar situation, although they are
still in very alpha stage: they use .rpm packages but not .deb, and if
they would (there are debian developers working to that project),
they'll be hurted by the same problems, when they'll release it.
Fabrizio
--
| fpolacco@icenet.fi fpolacco@debian.org fpolacco@pluto.linux.it
| Pluto Leader - Debian Developer & Happy Debian 1.3.1 User - vi-holic
| 6F7267F5 fingerprint 57 16 C4 ED C9 86 40 7B 1A 69 A1 66 EC FB D2 5E
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-request@lists.debian.org .
Trouble? e-mail to templin@bucknell.edu .
Reply to: