=emerge-delta-webrsync-3.5.1-r2 depends on tarsync like so: x86? ( app-arch/tarsync ) I think this is really incorrect. On one hand, x86 user may not want to use tarsync anyway. On the other, tarsync works fine with other archs (amd64 for sure). And if user has tarsync installed, eds will use it anyway. So what's the sense of forcing user to put tarsync into world file? I think tarsync should get his own USEflag in eds, allowing users of any arch to choose whether they want it or not.
Created attachment 187162 [details] Example ebuild with USEflag.
If I do what you suggest then I'll have to do a keyword request for tarsync on all the archs that emerge-delta-webrsync has keywords for. Since the tarsync upstream isn't really active and it doesn't have lzma support yet, I'm thinking about porting tarsync to python (and adding lzma support in the process). It shouldn't be much work and when it's python based I can automatically give it keywords on all archs (since python code is extremely portable all archs support python).
(In reply to comment #2) > If I do what you suggest then I'll have to do a keyword request for tarsync on > all the archs that emerge-delta-webrsync has keywords for. So maybe just add amd64 (and other arches tarsync has keywords for) to that DEPEND?
(In reply to comment #3) > (In reply to comment #2) > > If I do what you suggest then I'll have to do a keyword request for tarsync on > > all the archs that emerge-delta-webrsync has keywords for. > > So maybe just add amd64 (and other arches tarsync has keywords for) to that > DEPEND? That will require a stable request on amd64. I'd prefer to write a python version and do a stable request on that instead. Once that's done, I can remove tarsync from the tree.
(In reply to comment #4) > That will require a stable request on amd64. I'd prefer to write a python > version and do a stable request on that instead. Once that's done, I can remove > tarsync from the tree. And how is your python version? (;
Thanks for reminding me. Hopefully I'll do it soon. :)
(In reply to comment #6) > Thanks for reminding me. Hopefully I'll do it soon. :) Skip it. I originally wrote tarsync in python, I went to c since I couldn't make it fast enough to warrant it (full untar + rsync was faster)... tarfile is just a freaking slow implementation. A libarchive based version (pyarchive bindings specifically) is my long term intention. Related, tarsync upstream is active once again...
I plan to remove the tarsync dep from emerge-delta-webrsync and show a elog message in pkg_postinst recommending to install it if it's not installed already.
(In reply to comment #8) > I plan to remove the tarsync dep from emerge-delta-webrsync and show a elog > message in pkg_postinst recommending to install it if it's not installed > already. Switch to a use flag of 'suggested' or 'speed' or equivalent imo... It really is worth the dep where possible.
(In reply to comment #9) > Switch to a use flag of 'suggested' or 'speed' or equivalent imo... It really > is worth the dep where possible. Then I'd have to go through hoops to mask it on archs that haven't keyworded tarsync. No thanks. What's really needed is an EAPI extension for 'suggested' dependencies (or introduce a global 'suggested' flag and hardcode support for it in repoman). Anyway, I've removed the tarsync dep in cvs.
(In reply to comment #10) > What's really needed is an EAPI extension for 'suggested' > dependencies (or introduce a global 'suggested' flag and hardcode support for > it in repoman). …and then possibility of having multiple 'suggested' sets, then marking of RDEPENDs that could be changed without recompiling packages, etc., etc. IMO it's better to just leave it as is.