On Fri, Jan 11, 2013 at 06:41:36AM +0100, Martin Baehr wrote: > that's not what i meant. i am asking about cooking something that has > dependencies that are not already installed on fdev (but do exist in the fl > repo)
And I've been trying to say that in general, fdev isn't intended to replace a local development system. I'm saying that IF fdev has enough installed, it's OK to do local builds on it in order to test the build process. Additionally, we can install a few more packages from the repository to help with that. But we're going to stick with packages from the fl:2-qa groups and not install locally-cooked packages on fdev. It is a shared resource, not a private development machine, and I want to be able to update it sanely after updates to fl:2-qa. > which i take to mean i shouldn't use the rmake server for development > builds that are not for the repo... Its primary purpose is to build stuff for foresight repositories. If you need to do an rmake build that might not be ready yet for repositories but is part of building packages that will end up in foresight repositories, that's OK... I'm trying to give guidelines to help balance load between the systems, not make up arbitrary rules to make things harder. If you would have done a build in rmake on the old fdev, now do it on rmake.foresightlinux.org. If you ran screen, irssi, git, mercurial, ... on the old fdev, keep doing it on the new fdev. Does that make more sense? _______________________________________________ Foresight-devel mailing list [email protected] https://lists.foresightlinux.org/mailman/listinfo/foresight-devel
