Re: Removal requests submitted for CERNLIB packages
On Mon, Mar 07, 2011 at 08:46:15AM -0800, Kevin B. McCarty wrote:
>
> It's certainly fine by me, just be aware that I won't be able to
> provide much (if any) mentoring support. You and Bastien will need to
> find sponsors and/or join the Debian Science team for uploads. Do
> please re-read [1] one more time ;-)
Whoever wants to work on these libs should definitely join the Debian
Science team. I'm to some extend up for mentoring and sponsoring - I
guess there are some others hanging around here on this list as well.
> Looks like FTP-masters have been very responsive at following up the
> removal requests, so when you have packages to upload, they'll need to
> go back through NEW.
That's a bit unfortunate - but usually packages which was in Debian
formerly (and thus are fine license-wise) have a good chance to pass NEW
smoothly. I'd regard it a very good idea to announce the intend to
remove a package here before contacting ftpmaster.
> Sorry for the hassle, I hadn't thought anyone
> cared at all about these packages anymore based on the lack of
> follow-up on any FTBFS bugs.
I actually had some look into it a couple of weeks ago but have just
realised that fixing these was not as cheap as my time frame for this
task would have allowed.
> On the other hand, the packaging might very well benefit from a
> redo-from-scratch, as it's evolved very cruftily over the years. Part
> of the point of the extra cruft was originally that it should be
> possible for non-Debian users to be able to build easily from the
> source package, but maybe that isn't so important these days? A lot
> of the cruft is necessary though, as Cernlib's original source
> building infrastructure is an utter abomination.
I do not remember what package exactly was affected but I once had one
package which had several tarballs inside th eupstream tarball. It
might make sense to ship these as separate sources (but I might be wrong
here because I simply missunderstood the intention behind this).
> One issue that may have irritated upstream is the fact that Christian
> felt strongly about keeping the Debian packaging stuff in upstream
> revision control (so that users could run e.g. "make debian" to build
> .debs during the period in which there were not officially provided
> Debian packages). If he is no longer able to spend time on the
> packages, that's a decision that a new set of maintainers could
> conceivably revisit.
I'm always in favour of the contrary: The debian/ dir does NOT belong to
upstream. Those who might want to build Debian packages themselves
should rather visit our VCS (be it SVN or Git) and obtain the Debian
related stuff here. If this is the problem with upstream communication
we should be able to solve it quite simple.
Kevin, thanks for those detailed hints to your successors and thanks for
all the time you spended previousely in these packages.
Kind regards
Andreas.
--
http://fam-tille.de
Reply to: