Heinrich Müller posted on Tue, 27 Nov 2012 18:07:32 +0100 as excerpted: > Am 27.11.2012 05:52, schrieb Duncan: >> LOLed at your choice of example! =:^) >>> Being able to copy your config and use it with another account is a >>> good thing. >> I've wondered that before as well. Heinrich, is that an easy change? >> > Yes, I think so, but atm I don't code for pan, I've got other work to > do. I'm planning to implement pan in java btw. But only after I've fixed > some bugs that are in the java version. I think I'll do that in the next > 2-3 weeks.
Ugh. I hope I missed the sarcasm tags and that's a joke. Or at least that it'll be gcj buildable and not just runnable in a JVM. I don't have java VM on my systems ATM as I seldom need it and in general it's more problems than it's worth. The build-once, run anywhere thing just doesn't fit in a freedomwhere world, where it's simply a poor proprietary workaround to the /normal/ freedomware-world portability case of either the distro (for binary-based) or sysadmin (for source-based) building to the specific platform in the first place (assuming sources coded with portability in mind or later adapted for it), thus enabling the proprietary vendor to disrespect the four software freedoms of his users, to use, study, adapt and share the software sources as desired, by shipping obfuscated bytecode instead of the portable sources that are the normal portability solution in the freedomware world. I guess I could add a java VM, but last I checked, building it pulls in at least cups (which in turn pulls in its own deps), which I don't need as I have no printer, etc, and thus have USE=-cups set, to avoid the optional dependency. There's a Java VM binary available as well, but as all binaries on a rolling from-source system, that has its own problems, since the libs it depends on eventually get updated, often breaking at least the ABI (if not the API), which is normally fixed with a revdep- rebuild, but if it's a binary package, the revdep-rebuild doesn't fix the broken ABI that's the problem, it simply reinstalls the same broken binary, and the binpkg remains broken until it's rebuild upstream (distro or package) to target the new library versions. Unless of course you're aiming for gcj build compatibility, not just JVMs, tho that too would mean rebuilding gcc with USE=gcj, but that should be possible relatively less (hopefully MUCH less, tho I've never needed gcj and thus really don't know) trouble. That's one reason why java-based packages have remained relatively rare in the freedomware world, and often rank relatively low on the popularity index where they do exist. It's simply too much trouble (for user or distro packager), for relatively little gain. A gcj-buildable package may avoid some/all of that, but TBH I don't have any experience with it, so I really can't say. -- 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
