(Illustration by Gaich Muramatsu)
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. JanReceived on 2016-04-27 16:03:15