The latest (and only available) version is 7.16.2, requiring curl 7.16.2
While this is still a viable package for the Gentoo Portage tree it appears this ebuild is lacking in community interest. If you (or another user) are still wanting this to make it into the Portage tree please let us know! It would be additionally helpful (but not required) if you were willing to help out with the package by becoming it's proxied maintainer; you have already done most of the work for this task. Gentoo even has a dedicated team[1] for assisting users in becoming proxied maintainers. If you are interested in maintaining this package, please contact proxy-maint@gentoo.org or join #gentoo-proxy-maint on Freenode IRC. If this bug remains silent without further comments for 30 days i will close it with the resolution of WONTFIX. Beyond that the bug can always be reopened to get this package back on track for the Gentoo Portage tree. [1]: https://wiki.gentoo.org/index.php?title=Project:Proxy_Maintainers Tom D
Created attachment 437268 [details] ebuild for dev-tcltk/tclcurl-7.22.0 Just needed this package myself and wrote a simple ebuild for it. Build tested on amd64, but it should do just fine on other arches as well.
Thanks for contributing an ebuild! Due to a lack of activity surrounding Tcl/Tk and your need for the package, are you interested in proxy-maintaining it? You may want to look at our Proxy Maintainer project [1], which will paint a thorough picture of what you can expect by becoming a proxy maintainer. For the most part, you would be handling any bugs that occur for the package and I would assist you in ensuring the ebuild is up to standards. Aside from that, you would have autonomy, handling the package as you see fit so long as the tree (and this package, of course) isn't broken. :) If you accept, I would "babysit" the package and keep an eye on things. If anything needs my attention or input (commits, patch or ebuild review, etc) I would look into it. --- That said, the ebuild looks good but there are a few things we could shape up: * We can bump EAPI to 6 without any issues. * How are the dependencies, though? Under which circumstances would tclcurl need to be rebuilt? If it doesn't matter much on the Tcl version, then leaving that dependency bare (without ':0=') would be fine. If a curl bump will break tclcurl, then it needs the ':0=' so it will be rebuilt when net-misc/curl changes. I ask this so we're sure the dependencies are correct. They look okay at first glance, but without more specific knowledge (which you are more likely to have), I can't know which form is (more) correct. * The version information for the net-misc/curl dependency is redundant, since 7.21.7 was released almost 5 years ago and isn't currently in the Gentoo tree. So we don't need that version info. :) * The configure script supports --enable-threads, so it should have 'threads' in IUSE and honor it in src_configure. I can attach the ebuild draft I wrote to this bug if you'd like. It addresses the concerns I listed above. With the fixes, I think it'll be ready for the tree. Do you want to be proxy-maintainer? [1]: https://wiki.gentoo.org/wiki/Project:Proxy_Maintainers/Policies_and_Guidelines
Correction: We need a SLOT dependency for dev-lang/tcl, so it can be :0= or simply := if we don't care about version.
I honestly do not have that much more knowledge about the package than you probably have. I've never really looked at tcl and was quite happy to see that a simple ./configure && make && make install just worked, so that I would not have to. Since I saw this bug report I figured it would not be that much work to put this into an ebuild. With "I needed the package", I meant I was building another application that uses this library, not that I'm using it for development in tcl myself. That beeing said, about the dependencies: I think for curl as well as tcl the :0= dependency is the right way to go. This is what I could find: The libTclCurl7.22.0.so that is beeing build dynamically links against libcurl.so.4. This is what ldd says: $ ldd libTclCurl7.22.0.so: linux-vdso.so.1 (0x00000335dc352000) libcurl.so.4 => /usr/lib64/libcurl.so.4 (0x00000335dbcaf000) libssl.so.1.0.0 => /usr/lib64/libssl.so.1.0.0 (0x00000335dba30000) libcrypto.so.1.0.0 => /usr/lib64/libcrypto.so.1.0.0 (0x00000335db5b0000) libz.so.1 => /lib64/libz.so.1 (0x00000335db398000) libc.so.6 => /lib64/libc.so.6 (0x00000335dafed000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00000335dadcf000) libdl.so.2 => /lib64/libdl.so.2 (0x00000335dabcb000) /lib64/ld-linux-x86-64.so.2 (0x00000335dc132000) So I think we do need to rebuild if we have an ABI change in libcurl it must be rebuilt. So as far as I understand the slot operator, :0= should require the current API (slot 0), but trigger rebuilds if the ABI changes. Is that correct? As for the tcl dependency: there is no dynamic linking to the libtcl*.so from dev-lang/tcl. However, looking at the configure/ Makefile and the make output, it seems it is looking for /usr/lib64/libtclstub*.a to statically link that in. This is versioned with the current tcl version, i.e. libtclstub8.5.a currently. So I'd assume it'd better be rebuilt as well on version change of tcl. Therefore, I would assume the :0= is the right way to go (to stay with the api of slot 0, but rebuild on a sub slot version bump). Then there is the dyanamic linking against openssl and libz. I think we do not need to define a dependency here, as the -l flags are just pulled in from "/usr/bin/curl-config --libs" in configure. I.e., it should just link to anything libcurl does. And the curl ebuild does have those dependencies covered. I agree with you on adding the threads USE flag. As for the proxy maintainership: As I said, I don't know much about the package or tcl, I just used a tool that uses it. So if any bugs or security issues not related to the ebuild, but the package itself, would come up, I wouldn't really know how to fix it. Upstream does not really seem to be active, the last release is from 2011 and the website contains some broken internal links, which is not the best sign. However, the last release seems to be stable and still working with curl, so it might just not have been any need for new releases. (There is contact info of the author, who appears to also and still be the maintainer of curl/libcurl and might be very much responsive if anything would comes up.) So if you think under those conditions it is reasonable to include the ebuild, yes, I would be willing to do the proxy maintainership. I don't expect there to be much work to do once the ebuild is completed anyway, as there is probably not more development to be expected than happened in recent years.
Created attachment 437450 [details] tweaked tclcurl-7.22.0.ebuild Added a few more tweaks in addition to my previous comment: changed the license to match tcl/tk's (mentioned on the website and in the code), and ensured dependencies respected the 'threads' USE flag. We also didn't need the eutils class anymore since EAPI 6 supports user patching and the submitted ebuild wasn't using any of the eutils functions. It's no big deal. Regardless, thanks for taking the time to write the ebuild! Good point wrt the dependencies. We'll go with :0= for both since it makes the most sense. Additionally, tcl and curl both also support USE='threads', so I added that to RDEPEND, since it doesn't make much sense to run threaded tclcurl on a Tcl or curl that isn't also threaded. If the maintainer of tclcurl is also the author of curl/libcurl upstream, then odds are this tool will be worth keeping around since he understands the library he's linking to. At any rate, if there are any issues like security bugs or other tough situations, it's our job as Gentoo developers to help you out. We won't leave you out in the cold. :P I've attached the updated ebuild to this comment and will touch base with the proxy-maint team to make sure I've not forgotten anything. Are you fine with your bugzilla information being used in metadata.xml and in your maintainer bug? There's a few steps we (read: I) will need to take to make sure your contributions get tracked and credited, then I can add tclcurl to the tree. Thanks for getting back to me in such a quick manner.
Yes you can use my bugzilla info. How does committing changes as a proxy-maintainer work exacly? Do I add you to CC on a bug report in case I want to propose to commit a change or should I communicate that with you through other channels?
That generally depends on the severity of what you want to propose. If it's a big deal, we may want to keep it public. If it's a typo fix or some other correction that won't affect users, something informal over IRC or e-mail would be fine. If you need to make it public, then yes, you'd add me and/or proxy-maint@gentoo.org so I or we can take a look at the proposed change. I'm a bit busy later today, so I won't be able to get your maintainer bug started right away. You're free to do it yourself according to the wiki page[1] if you'd like. Just CC me so I can follow. Otherwise, it may be a day or two before I can come back to this. Just wanted to give you a heads-up. [1]: https://wiki.gentoo.org/wiki/Project:Proxy_Maintainers/Maintainer_Bugs_and_Maintainership_Requests
