Hi, On Sat, Jul 24, 2004 at 13:43:40 +0200, Giulivo Navigante wrote:
On 07/21/04 09:26:59, Johannes Winkelmann wrote:
I'm obviously not speaking for the CLC project; personally, I'm more than happy to have non-x86 ports at CLC (even though I don't believe in a CVS based solution ;-)), but at the current point in time I don't think giulivo or "ncrfgs" are good matches for our team.
anyway, as i've wrote in the first email, our intent is to improve crux ppc and have a better integration between clc's ports and crux ppc
in that message i can read this:
do you think is possible to work on this issue in the next months? Well, depends on your definition of integration. If your idea is to develop it in a common Revision Control Repository, the answer is 'no', CVS isn't suitable for this, and we're not planning to move away from CVS (or to put it differently: I'm not aware of a revision control which offers all the advantages of the current CVS & CVSUp setup in terms of network traffic efficiency, support for our "moving tags" and simple usage as a ports backend). Of course, a lot can change in the next few month, but we're at least not planning to switch at the moment.
what kind of solution would you suggest? we are ready to contribute in anyway could be useful. We (the maintainers I've discussed this with so far, not CLC as an entity) would suggest that you maintain PPC specific ports (yaboot etc) and ports from CLC which require changes to work on PPC (mplayer, openoffice-bin etc) in your own repository, so CRUX PPC users can get your tree and the one from CLC and have all ports in a working state;
This doesn't mean that we want to stick with CVS by any means possible, but I'm not aware of a solution which is as good as the CVS/CVSUp based one (Subversion isn't, SVK isn't, monotone isn't, gnuarch isn't). But of course if you find something which would allow this, we would definitely consider making the switch. And obviously we're looking at those revision control systems anyway (some of us at least), so if there's going to be a good alternative to CVS, we might switch just for the additional features. We're not actively looking for a solution to integrate your ports tough, but of course, you're invited to do so. they just have to look in your ports directory first. I personally would probably have a complete tree synced and adapted from the one from CLC, since you have to check every single port anyway to be sure that it works on PPC; you might have a different point of view on this though. Of course, using this solution, your users would get only those ports which are known to work, and you don't have to worry about any change in our tree breaking any of your PPC user's build. The more, they only have to fetch one tree. If there are ports which don't work on PPC because the they are x86 specific without good reasons (like hardcoded CFLAGS and the like), please report this as a bug and we'll try to fix it.
so, about the problem, which are the results? we have to work on the CVS? we have to use mppm? we have to write new code (and make johannes happy)? Basically, you don't have to do anything. It's about what you want to do.
CVS is not suitable for this task, so you don't have to use it. What ever tool you use to maintain, sync and merge your tree (see above) with the tree from CLC is really up to you. mppm can do it [1]; I'm not aware of any other tool that does exactly this, but you might be lucky finding one. To keep your copy up to date, we offer cvsup access and httpup; at least the later should work fine one most platforms, so this shouldn't be a problem. And you won't make me happy by writing code (neither with statements like the one above), but by solving problems. If course, the former can lead to the later... Kind regards, Johannes Notes: 1. mppm will need further work to become faster and more mature; I'm more than happy about feedback, problem reports and suggestions, though -- Johannes Winkelmann mailto:jw@tks6.net Bern, Switzerland http://jw.tks6.net