[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Re: gcj4 changes : Please Comment



On Sat, Feb 26, 2005 at 04:53:08PM +0100, Daniele Cruciani wrote:
> 
> Dan Weber:
> > 
> > If people are interested in native binaries, they'll do it.
> 
> If people are interested in gentoo they'll install gentoo.
> 
> Sorry, most of the time I do not have spare space for compiling natively
> package, thus I take a Debian binary CD and install what is inside it.
> 
> If your are talking about unstable distribuition and how much
> time/resource is spent for building -jni packages, it is another matter.
> But for a release or for a security fix having system unusable because
> compiling is not the gentoo way, it will be a Debian wrong way: figure
> that you want a tomcat compiled natively, how much time you have to wait
> before having a working system? Also, how many headers package one have
> to install for building native interface?
> 
> Having native package is not a matter of taste: it reduce memory
> requirement and run faster. Most user should install native packages. If
> native replication of package is confusing the .so file should be
> included in package merging the 2 packages (actually lib packages are
> supposed to be binary).
> 
> For unstable (do not stress autobuilder and mirrors problem): how does
> will be managed the needs for missing headers? Does debconf should just
> stop saying "something go wrong, sorry"?
> 
> Shortly, I disagree with your idea and with Daniel Bonniot's rationales.

We speak about compiling jars to native. Not about JNI code or missing
headers. If you want to run a jar you already have all its prerequistes
on your disk. Its just a matter of time and memory to create the native
libraries out for the jars.

I,m not a friend of doing it on the users machine. I Would like to make
it on the autobuilders. This means we need to introduce extra packages
for the native java stuff. I think there is no real solution around
this. Putting the work on the users machines is no solution.

We can make the packaging work easy by providing a script that can
compile jars to native in some central package like cdbs. This will
minimize the changes need to the existing packages but we will need new
binary pacakges.



Michael



Reply to: