Mailinglist Archive: opensuse-project (168 mails)

[Adrian Schröter <adrian@xxxxxxx>]

Am Freitag, 20. April 2012, 12:20:45 schrieb Pascal Bleser:
> On 2012-04-20 09:55:44 (+0200), Adrian Schröter <adrian@xxxxxxx> wrote:
> > Am Donnerstag, 19. April 2012, 22:21:52 schrieb Angelos Tzotsos:
> > > There was a small discussion among Application:Geo project members about 
> > > this issue today.
> > > I was asked to bring this issue to this list so that we can all discuss 
> > > it.
>
> > > The problem:
> > > Currently it is forbidden to package binaries in OBS without building 
> > > from source code. This causes issues when we need to build very complex 
> > > Java applications or web applications (eg like Geoserver, Geonetwork, 
> > > JOSM etc). In Java it is nearly impossible to build everything without 
> > > bringing jar binaries in the game at some point (eg maven depends on 
> > > itself to build). If we want to do this without binaries it would take a 
> > > very large effort for many packages and it would be a dependency 
> > > nightmare for packagers.
>
> > > On the other hand, the build.o.o instance has open source and 
> > > transparency in mind, so the policy to request sources and not binaries 
> > > is fair.
>
> > While I think it is not a good idea to have exceptions, some exceptions
> > for very few packages to be able to boot strap may be okay from my POV.
> > On the other hand, all other languages, like C/C++/C# or even pascal and 
> > haskal can boot strap themselfs. Why should java be an exception?
>
> Sorry, very long email ahead, but I'd like to clarify a few
> points to not have to argue about them again and again ^^
>
>
> Java can bootstrap itself. OpenJDK bootstraps from C (the kernel
> of the JVM (Java Virtual Machine) is written in C).
> Maven can bootstrap itself too, and does so, actually.
>
> It _can_ be done, and is done for OpenJDK at least, that's not
> the issue. It is a question of effort vs benefit.

I aggree.

> If we take the example of Maven, which is particularily painful
> because it is pretty complex to build by bootstrapping and by
> using our "Linux" (rpm/deb) technical model for "packages" and
> "dependencies":
>
> Maven, as most Java based things, is designed to be portable
> across all operating systems that can run a JVM (of a certain
> version)

I admit, that I do not have any inside of maven. But when we can
not create multiple packages, it is still better to create one big
package, but generate everything from source there IMHO.

> For that reason, and because another unfortunately quite
> prominent operating system does not have a comparable package
> management model (*), it does not use a portable way of
> installing components of software other than just files that are
> downloaded and put somewhere (in the case of Maven, that's
> ~/.m2/repository).
> On a side note, that is an approach you will find with -- as far
> as I know -- every other build tool for Java projects which does
> dependency management (ivy (which is an add-on for Ant), gradle,
> etc...)

When it can not be done inside of rpm, maybe it is up to the users
to install it with their tools (similar to gem). But it should not
be part of our distro. And currently we consider everything inside of
build.opensuse.org as a potential candidate for openSUSE (can be
discussed as well of course).

> +-+-------------------------------------------------------------
> | (*) To prevent off-topic discussions about Windows and MSI:
> +-+-------------------------------------------------------------
> |S| Yes, it has, to some extent, but it has always and partly
> |I| still is very difficult to use, and simply isn't the model
> |D| that has developed with its users: Windows users have always
> |E| and will always just download archives somewhere and use them
> | | from there, without much system integration -- nothing
> |N| *prevents* java archives to be used and handled centrally in
> |O| the same way as DLLs (well, sort of, for some of them ...) or
> |T| in the same way as it is done on Linux, but it is simply not
> |E| how Windows users and developers do it, for whatever reasons
> | | (I have a few ideas about those reasons but won't mention
> | | them because I don't want to be rude).
> | |
> | | In any way, let's not discuss this here, it is irrelevant.
> +-+-------------------------------------------------------------
>
> Hence, we are faced with two different models of managing
> dependencies and, in a way, the Java approach is a lot more like
> MacOSX' DMG, or klik on Linux, or just prehistoric zip files on
> Windows, which is to include most dependencies (libraries,
> tools) as part of an "image" of some sort (which is usually a
> tarball or a zip file).
>
> So, the real question is: do we want to fight an uphill battle
> against what 95% of Java developers are doing, or even forced to
> do as that's what their build environments are doing and
> transform every possible Java based piece of software (**) we
> want to have in the distro or repositories into our RPM
> philosophy/approach (***), or do we want to be more pragmatic
> about it (being aware of the tradeoffs) ?
>
> (**) which spans a very broad horizon from desktop sorts of
>      applications (including things like Eclipse and Netbeans)
>      to server-room stuff like Tomcat or JBoss
>
> (***) which is to remove all the Java libraries (jar files) that
>       are shipped with a Java software distribution or retrieved
>       using mechanisms such as Maven's, and instead have those
>       as individual dependencies -- e.g. remove xerces from ant
>       and have ant use a system-wide xercesImpl.jar from
>       /usr/share/java/...
>
> Okay, now that you've answered that question for yourself
> thinking about Vuze or Eclipse or Netbeans, ask yourself the
> same question again in the shoes of a system administrator with
> Tomcat or JBoss.

Frankly, you as java developer. Are you using our rpms at all?
Or do you prefer to install the latest version yourself as jar file?

In my personal POV, it is better not to ship this software then to
break our promisses, we usually gave when shipping rpms. We do promise
that the stuff is reviewed and we are able to fix it in a compatible way
_ourself_. Anything where this is not true should not be part of our distro
IMHO.

...
> > The other side are add-on packages for libs and applications. I personally
> > see no reason why we should become just a binary only hoster here and have
> > an exception just because it is written in java.
>
> Very clearly: convenience for users (which very explictly
> includes system administrators).

You would win some users here and loose others, maybe more important ones on
the other side. Eg. companies who want to preload our stuff, but we
won't be able to give any guarantees for our stuff anymore.

...

> > Esp. when you look at the current Google vs. Oracle fight, it
> > makes it actually obvious for me that we need to be able to do
> > a legal review for the java stack.
>
> Are you sure that you understand what you are talking about ?

I had esp. the copyright violation in mind. Oracle showed that they
are willing to sue others when they copy non-free stuff from them.
And exactly this information is lost when you have just jar files.
Our license digger will be able to detect such copyright violations
anymore (and it does find quite some issues in the factory submissions,
all of them would be not deteced anymore).

> > The downside might be that we loose quite some packages
> > because we do not have anyone able or willing to package it
> > anymore. Can we live without Eclipse, josm and friends?
>
> Well, assuming you mean "without Eclipse *packages*"

yep

> , yes and
> no:
>
> * yes, because there are other ways of installing java based
>   applications and libraries (I personally just pull eclipse
>   from eclipse.org and put them into some directory under my
>   home), especially for desktop applications
>
> * no if in any way we want to attract more developers (tools
>   such as Eclipse, Netbeans, Maven, Ant are paramount to doing
>   so, and I'm not only talking about Java developers)
>
> * no if we want to provide packages of more server oriented
>   applications such as Tomcat, JBoss, Wildfire, Tigase, ...),
>   which are obviously much more interesting to install in a
>   system-wide way using our usual mechanisms (rpm, zypp).
>
> > Open question is what is more important here.
>
> Certainly, but the other question is whether we want a holistic
> or a pragmatic approach. Or, rather: can we live with a more
> pragmatic approach ?
>
> Personally, I believe that sticking to the holistic approach
> ("always build from source, always. period.") just for the sake
> of sticking to it is stupid.
> If we are aware of drawbacks, it should be perfectly fine to
> make exceptions, if the advantages are worth those drawbacks.
> Which kind of brings us back to your question :)
>
> My personal opinion: hell yes, there are packages where the
> drawbacks are worth the benefits. But there are also lots of
> others where it isn't.

I am still obsolute 100% behind that the openSUSE distro must be
fully open source and being manageable by us (or everybody who
is able to work on sources).

It might be okay that we define some other namespace in OBS where 
these rules are explicit not required.
(Btw, the todays german court decision between YouTube & GEMA
 showed that courts may require us to screen submission from
 users before making them accessable. But that has only partly
 some effect here).

-- 
Adrian Schroeter
SUSE Linux Products GmbH
email: adrian@xxxxxxx

--
To unsubscribe, e-mail: opensuse-project+unsubscribe@xxxxxxxxxxxx
To contact the owner, email: opensuse-project+owner@xxxxxxxxxxxx