Re: Policy exceptions?
In an attempt to save the world from disaster, Magosanyi Arpad wrote:
> On Tue, Feb 10, 1998 at 05:51:45PM +0100, Luis Francisco Gonzalez wrote:
> > Hi,
> > I have been pondering something similar. DMALLOC, is a malloc debugger library.
> > When I took over the package I split it in two, a shared library and the
> > corresponding development kit but in all honesty and with hindsight I think
> > this is just wrong. There is never going to be a reason for creating packages
> > that depend on a dmalloc shared library other than dmalloc itself. So the
> > question is, should I join everything back into one package and ignore the
> > policy in this case?
> No. I don't think that you can be sure that noone ever will use your library
> for other programs it is designed for.
One can never be sure, of cource. But the point is, that, especially for
a malloc debugger, it is exceptionally likely that no other package is
ever going to depend on it.
Really, if ever someone comes along and does show us a good reason for
an other package to depend on a malloc debugger lib, then the malloc
debugger can always be split again.
> The simplest cases:
> -someone creates another interface for the same task with the same library
> (e.g. X gui)
Well, that is certainly not going to happen with a malloc debugger, is
it?
> -someone writes a program which uses a helper function from the lib, just
> for convenience.
Like what function exactly? And why? To crash a user programme more easily?
Please remember what a malloc debugger is for. It's to find bugs, not
to run other programmes.
> I think that there are good reasons for this policy.
Yes, there are _very_ good reasons for forcing maintainers to think hard
before they disobey the policy on this point. But in this case, I really
think the maintainer has thought hard enough, and he is right: no-one
will in the forseeable future want to make another package depend on
a malloc debugger.
So, at the moment, the two packages that could be one simply eat up
extra diskspace (two seperate files compress less well, all have some
extra blurb double, etc, etc), use more time from those thousands of people
that install debian (they now have one more package description to read,
deside weather to install or not etc. At least 5 seconds per user. Estimate
the total time loss at about a day).
In the _very_ unlikely event that ever someone does want to make something
depend on the malloc debugger, the package can always be split.
In short: yes, the maintainer should not be allowed to disobey the policy
on this point, without a well thought out argument as to why he wants it.
I do not know whether I agree with the original poster, sgb: he didn't
give enough details as to why he thinks no-one will want to link with his
lib. But also he may be right.
--
joost witteveen, joostje@debian.org
The upstream maintainer is allowed to do things different
than Debian, but only if he has good reasons to do so.
--
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: