Re: [Pan-users] What tells Pan where to save??

[Duncan]

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