Custom Query (196 matches)

We currently install a bunch of Perl CPAN modules, Python eggs, and Ruby gems behind RPM’s back. But we have no plan in place for upgrading them, making sure they don’t conflict with RPMs, or making sure they get superseded by new Fedora packages when they become available. This is a disaster waiting to discovered.

Everything should be an RPM. There are tools for automatically converting these creatures into RPMs, such as cpanspec, setup.py bdist_rpm, and gem2rpm. We should start using them and get rid of all the unpackaged modules lying around.

Most of our software supports upgrading by switching to a newer tag, updating, and possibly running an upgrade databases script. If we install a SVN (or whatever VCS) working copy rather than extracting a tarball, users can upgrade their own installs easily. Our auto-upgrade process should also become easier.

For SVN, we can merely generate a tarball with the .svn directories and keep our existing auto-install (and to some extent, auto-upgrade) infrastructure. I suspect this will work with all other VCSes.

There are also packages such as Django that very much recommend installing HEAD rather than a tarballed release, so having an infrastructure that will deal with VCSes will make it easier to support such packages.

In order to ease password changes (see also #227), follow DRY, etc., autoinstalled apps should read the sql password out of ~/.sql/my.cnf rather than copying it into the app config.

For Django, ​https://docs.djangoproject.com/en/dev/ref/databases/#connecting-to-the-database may be helpful.