walt posted on Sat, 04 Jul 2015 08:22:37 -0700 as excerpted: > On Sat, 4 Jul 2015 05:06:46 +0000 (UTC) > Duncan <1i5t5.dun...@cox.net> wrote: > >> walt posted on Fri, 03 Jul 2015 16:30:42 -0700 as excerpted: >> >> > On close inspection of the cached files I see that the original >> > article was posted using a news client that was compiled from git >> > repository source code. >> >> What was that client? Not pan, was it? Linux platform? MS? Something >> new, perhaps on github, or an older, traditional client, >> now moved to git for development? > > https://github.com/madcowfred/newsmangler > > It turns out to be pure python with no gui. Very nerdy indeed. The > author tells us that it's no longer maintained and points us to a more > recent version, also hosted on github, and written in Go. Go figure.
Interesting, particularly in the timing... As regulars no doubt know by now I've been a gentooer for over a decade now. While I'm not a gentoo dev, I follow the gentoo-dev list, for among other reasons, to get a heads-up on package changes that are likely to affect my system. ATM, there's a thread on gentoo-dev discussing go-based packages, and the best way to handle them. Gentoo's "packages" are called ebuilds. These are basically fancy shell scripts defining specific functions that the package mangler handles in a particular order (unpack comes before prepare, which is followed by configure, compile, (fake-)install (to temporary location), quick-merge (to live filesystem), post-install, in that order, with hooks for local-system function hooks available as well). Many, probably most ebuilds, inherit eclasses as well. These eclasses serve as libraries for functions called by many ebuilds. And the gentoo-dev thread is about setting up a couple go-targeted eclasses, to be used in go-based-package ebuilds. Go-based applications turn out to be an interesting case to package, because while they do have libraries, all libs are static-only -- they are normally built as part of the application build process and get built into the final binary. So the discussion has been about how to handle these static-only go-based- libs, particularly when many of them either don't have a formal release process, or don't keep sources tarballs around for previous releases, so the only way to get them is either to pre-fetch the sources, tarball them and put the tarballs on the gentoo mirrors, or do a live-VCS build that fetches from git or wherever, and checks out a particular tag or snapshot for the build. The debate is around whether to let go's own go build (or whatever it is) process automatically fetch and build everything, thereby repeatedly building libs if they are used by more than one package, or whether to separately package and build the libs, so they're available at build-time for the apps that need them, even tho there's no runtime component as they're static-libs only. Plus all the various details, of course. And once all that is settled, the agreed approach will be setup in the go- targeted eclasses, which can then be used by whatever go-based ebuilds end up being created and added to the tree, plus of course, once they're created and available in the main tree, various overlays can use them as well, for go-based packages that don't make it into the main tree. OK, so following the debate has been interesting, in a generic way, but until now I hadn't the slightest hint of any go-based packages I might have the remotest practical interest in. Now I read about this go-based news client, and suddenly, all that debate is at least somewhat relevant! Not that I'm actually thinking of trying it; pan has been quite good to me over the years, but at least I have /some/ concept of an actual go-based package for something I actually do a bit of personally, even if I have a different app to handle things that I'm quite happy with. Meanwhile, all this supports the point I was making earlier about side discussions suddenly proving relevant. Reading that thread on the dev- list, I had no clue I'd come across a go-based news client here, making that thread at least somewhat relevant. And reading this thread here, I had absolutely no clue go was going to suddenly popup in the middle of it. But the two entirely separate threads on two totally different lists, suddenly make each other relevant! It's exactly that sort of totally unexpected connection that continues to keep newsgroups and mailing lists exciting for me, even after I'm familiar enough with the subject matter that to the degree one can predict things, anyway, it should long ago have bored me to death, or at least to the point I dropped my participation in that group/list. =:^) -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman _______________________________________________ Pan-users mailing list Pan-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/pan-users
