[clc-devel] clc ports and crux ppc

Johannes Winkelmann jw at tks6.net
Sat Jul 24 14:28:32 UTC 2004


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.

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.


> 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;
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 at tks6.net
Bern, Switzerland                http://jw.tks6.net



More information about the crux-devel mailing list