Spec URL: http://sdz.fedorapeople.org/rpmbuild/rhino-appjet.spec SRPM URL: http://sdz.fedorapeople.org/rpmbuild/rhino-appjet-1.7-0.1.R1.fc14.src.rpm Description: Package is required for Etherpad!
I propose contacting rhino maintainer(me) and working together to get this both upstream and in our package. Having same source with one additional patch as additional package is not the way we are supposed to work. This means that you will have to update your patch for 1.7R2 of course.
Actually I'll take this one to be sure that we will work it out.
Any progress ? If not I'll close this review in 2 weeks.
I'm trying to figure out how to proceed here. Appjet is its own framework and I'm leaning to argue that it needs its own package. It was part of the initial etherpad package and I'm not sure whether the patch (or porting it) will affect other rhino apps. Can you maybe have a look at the patch?
Well, if you give me some unresolvable reasons why appjet requires its own framework you might convince me. But I don't see any reason to not move to latest rhino even if the patches are unavoidable.
Well, so the thing is that yuicompressor breaks significantly if anything other than rhino 1.7 R1 is being used. And appjet apparently needs it's own versions of rhino and yuicompressor, which is why this looks like a butchered version of a rhino 1.7 R1 compat package. Now I just found [1] which might be a way around all this but didn't exist at the time when I filed the review. I'm not sure whether this would work with the appjet changes, though. [1] https://github.com/tml/yuicompressor-js170
(In reply to comment #6) > [1] https://github.com/tml/yuicompressor-js170 This link 404s for me.
That is very true. Sorry. The developer apparently changed the repository name. Here it is now: https://github.com/tml/yuicompressor Mat, do you think this might be useful?
(In reply to comment #5) > Well, if you give me some unresolvable reasons why appjet requires its own > framework you might convince me. But I don't see any reason to not move to > latest rhino even if the patches are unavoidable. Sorry for taking so long to get back to this. So, let me try pitching it this way: Etherpad's Appjet requires both a modified version of yuicompressor (and hence rhino). I'm not comfortable arguing that these patches won't affect anybody else using rhino -- simply because I don't know. I have tried compiling etherpad against upstream versions of rhino and yuicompressor, but it throws errors during the compilation. I feel that it'd be fair to argue that in this case patched compat packages for both rhino and yuicompressor could be doable. Did I convice you? :)
(In reply to comment #9) > (In reply to comment #5) > > Well, if you give me some unresolvable reasons why appjet requires its own > > framework you might convince me. But I don't see any reason to not move to > > latest rhino even if the patches are unavoidable. > > Sorry for taking so long to get back to this. So, let me try pitching it this > way: > > Etherpad's Appjet requires both a modified version of yuicompressor (and hence > rhino). I'm not comfortable arguing that these patches won't affect anybody > else using rhino -- simply because I don't know. I have tried compiling > etherpad against upstream versions of rhino and yuicompressor, but it throws > errors during the compilation. > > I feel that it'd be fair to argue that in this case patched compat packages for > both rhino and yuicompressor could be doable. > > Did I convice you? :) And before I forget, upstream has been notified awhile ago, so there'd be tracking of the situation: https://github.com/ether/pad/issues/173
I give up on this one - I see no hope for proper resolution of the issue.
(In reply to comment #11) > I give up on this one - I see no hope for proper resolution of the issue. OK, after one more year I close this review request, adding it to FE-DEADREVIEW.