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