> Thanks much for your message and all your hard work. We had a long > time ago agreed to go with 3., simply because of the fact that the > octave-forge.eclass does most of the work at this point and there is > hence no good reason to add a new category to the portage tree which > contains many tens of split octave-forge ebuilds that by themselves > simply call the eclass and hence don't do anything but waste space. > > That said, we need somebody to spearhead the effort in writing > g-octave. Unfortunately, this can not be me since I am currently > simply too busy at work and otherwise. Maybe we could use this as an > opportunity to get things started. We need one or two people that > feel comfortable to take a stab a g-octave (based on g-cpan maybe) > and write a first prototype. Any volunteers? > > Best, > Markus
But, IIRC, g-cpan is used mainly for makind ebuilds for perl packages, because there are a lot and they are in their repository, with their deps and everything. octave-forge packages are hosted in sourceforge as regular tarballs, they are updated and maintained by the same group of people, there are only a bunch of them, and they don't have their deps listed anywhere but in their webpages. I can't see how a g-cpan-like app can help us with this.
signature.asc
Description: This is a digitally signed message part.
