Re: problems with upstream authors and the naming of perl modules
On Fri, 30 May 2003 22:34:01 -0400, Joey Hess <joeyh@debian.org> said:
> As far as some kind of quicker fix goes, I proposed some time ago
> that policy be amended to let the libfoo-bar-perl just be provided
> by the package, if it made better sense to use something else for
> the package name. Though that proposal has been stalled for *years*
> (I'm offline, so I cannot look up why, it's policy bug #114920), if
> I were you I'd go ahead and do that here.
Partly a matter of tact. I lose interest in most proposal that
call work done by other developers foolish; the resulting distaste
makes one less willing to personally pudh things ahead. This may well
be foolish, but since one has been called so already ...
And the issue of versioned provides: it requires there to be a
transition plan, unlike what the original report stated, while
packages that depend on some version of plibfoo-bar-perl are changed
to depend on the different name of the apckage. It also creates some
confusion; some packages depend on the long virtual package name, and
other who depend on the ``real'' package name with versions.
Does aptitude allow one to search for libmime-tools-perl if
that is merely a provides header?
The original message offered long names of packages as the
rationale -- though not unsympathetic to that, I didn't consider that
worth the pain of coming up with a transition plan, and implementing
it (and we do need something; putting a should directive in policy
make packages not following the should buggy).
In order to get this moving one needs to see if the should
would be better replaced with a may (which may have been the original
wording), and to work out a transition plan; once it does not make
all packages insta-buggy, and there is a road map to follow, it'll
have a batter chance of make it it into policy. I suspect it would be
easier if the perl package maintainers had buy-in in to this proposed
policy, and would arrange with maintainers of dependant packages for
a smooth transition.
manoj
--
Karl's version of Parkinson's Law: Work expands to exceed the time
alloted it.
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/%7Esrivasta/>
1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Reply to: