On Fri, Apr 22, 2016 at 09:06:02PM -0500, Adam Goode wrote:
> On Fri, Apr 22, 2016 at 8:34 PM, Jan Harkes <jaharkes_at_cs.cmu.edu> wrote:
> > It doesn't help that the packaging files are part of the source tree so
> > any packaging problem requires a rebuild of the source archive, that was
> > probably mistake #1. The fact that any scripts I used to use are no
...
> I recommend removing the specfiles from your repository. They are
> distro-specific and should be stored in the distro's repositories. Here are
> Fedora's:
> http://pkgs.fedoraproject.org/cgit/rpms/lwp.git/
> http://pkgs.fedoraproject.org/cgit/rpms/rpc2.git/
> http://pkgs.fedoraproject.org/cgit/rpms/rvm.git/
> http://pkgs.fedoraproject.org/cgit/rpms/coda.git/
> 
> Although it looks like coda has been retired from Fedora from lack of use.

Good recommendation. I 'forked' a package we already had for another
project in our group and turned it into a Coda packaging repository that
holds all the Debian/Ubuntu/Fedora/RHEL packaging related chaos.

    https://github.com/cmusatyalab/coda-packaging

The good part is that now we have proper package signing and something
of a manageable workflow to consistently build binary and source packages.

The not-so-good part is that it became pretty much impossible to
correctly build from separate source archives and so lots of things got
shuffled around.

  liblwp/librpc2/librvm -> coda-common package *1
  codaconfedit          -> coda-common package *2
  lib*-dev              -> not packaged
  rvmutl/rdstool        -> coda-server package *3

*1 no actual conflicts with the old library packages because we install
   them under /usr/lib/coda/.
*2 conflicts with old coda-client and coda-server packages, but makes
   installing clients and servers on the same machine more straightforward
   without needing special diversions.
*3 only used by the server anyway, does introduce a conflict with the
   old rvm-tools package.

Also because I based the RPM build on the Fedora spec file, the
enterprise linux family (RHEL/CentOS/...) is currently not building. el6
is broken because it doesn't have systemd, and el7 is broken because it
probably uses a different package name for the readline5 library
hopefully in a couple of iterations those platforms will build again.

> If you want to do binary packaging, you might consider making a Docker
> package.

Not sure if you are joking or being serious here.

Jan