Uncoordinated upload of the rustified librsvg

[Manuel A. Fernandez Montecelo]

Hi,

2018-11-06 14:19 Jeremy Bicha:
>
>It looks like we will want to have a librsvg-c source package to build
>the older librsvg for architectures that don't support Rust yet.
>
>While the Debian GNOME team could maintain librsvg-c's packaging
>alongside librsvg, I'd be happier if someone who cares more about
>ports would maintain it. Any volunteers?

tl;dr:
It might sound as if I what I'll suggest is to put back the work for you
gratuitously, but I honestly think that you (GNOME team) should keep
being the maintainers of a re-uploaded librsvg-c package, at least for
the time being.

Long:
... For the following reasons:

1) You've been maintaining it for years and have the experience (cadence
   of releases/updates, upstream repos and bug trackers, etc), while
   anyone else getting involved now will not have such experience,
   unless they have been in contact with this library or maintenance of
   GNOME packages before.

   Of course, if anyone volunteers, great, either as part of GNOME team
   or independently.  From my side, I am already struggling with what I
   have and I am planning to reduce my involvement in some areas.

1.1) I think that at least the initial job should be done by you as a
     kind of "orphaning" and moving it to QA, if you really don't want
     to maintain it from day one.

1.2) The librsvg-c has to be in sync with the -rust one and be uploaded
     in lockstep if the package binary names change, or have to conflict
     for one reason or another, so it has to either have the same
     maintainer or have close coordination.

2) I hope not, but if the new Rust implementation becomes problematic
   for stable-release arches, GNOME might need the C implementation in
   some of them, or alternatively dropping GNOME completely on those
   arches.

   If those stable-release arches do not have GNOME or any librsvg
   available, for sure they will drop as stable-release arches, since
   the requirement of building 98% of the archive will not be met.

3) Presumably the maintenance burden will be low, if that C
   implementation is dead, and will only need security fixes if Suse,
   RedHat and similar distros still maintain it, which I guess they do.
   And since it will not affect the most popular architectures or stable
   releases, it will not require urgent action.

5) From what you said in another email of this thread, I was surprised
   that you consider "ports" as a kind of "nonfree" and, in a way, not
   part of Debian.  For me, it's just about the same as breaking
   rev-dependencies: some arches have more users that many packages
   which are rev-dependencies of a given package, and breaking rev-deps
   when updating packages is generally frowned-upon.

   But let's leave that aside.

   Nowadays most of the architectures in Ports are from hardware "on its
   way out" due to being proprietary and not being produced anymore
   (alpha, hppa, etc) or playing around with other kernels.

   But Ports was also originally, and nowadays primarily, the way into
   Debian-Stable for new architectures.  Not long ago (2014-2015) three
   architectures entered Debian in such a way and they are now release
   architectures: arm64, ppc64le and mips64el.

   Maybe they don't rank high in popcon because they don't have it
   enabled, but there many people using arm64 in boards or laptops, and
   there are institutions running whole clusters or supercomputers, or
   workstations (but that's mostly x86_64 nowadays), doing science or
   serving faculty and students.  Some of them even use GNOME --
   probably not the ones in supercomputers though ;-)

   You'll want to have GNOME users in the next big architecture, and
   that architecture will come trough debian-ports.

   So independent of all else, I think that debian-ports is way more
   important than non-free, on which very few people relies upon except
   for firmware.  But people in this thread seem to think otherwise,
   so... dunno.


>At a minimum, I don't have an easy way to do the initial binary build
>of librsvg-c required for the NEW queue.

There are porterboxes for that, but if it helps, I can build it for you.


Cheers.
-- 
Manuel A. Fernandez Montecelo <manuel.montezelo at gmail.com>