LWN: Comments on "Callaway: Chromium: Why it isn't in Fedora yet as a proper package"

Callaway: Chromium: Why it isn't in Fedora yet as a proper package

ceplm — Thu, 04 Feb 2010 19:40:53 +0000

I was still around Debian (couple of years ago) when there was a serious security bug found in libz (compression library behind gzip and many many other programs). Suddenly all Debian maintainers were running around and finding more and more copies of libz in source trees of their applications (heck, even kernel had one for ppp). Something which would couple of lines fix in one package, was a month long disaster which took a lot of time and effort. I remember it well as a lesson why this "Java" (not limited to Java) approach is completely insane and irresponsible. Are you sure that Google fixed that security bug in (say) libpng which was discovered last week?

Callaway: Chromium: Why it isn't in Fedora yet as a proper package

ceplm — Thu, 07 Jan 2010 22:53:07 +0000

You obviously never tried to package Amaya ;). Oh well, one of the biggest
perpetual source of frustration and disappointment.

Callaway: Chromium: Why it isn't in Fedora yet as a proper package

ceplm — Thu, 07 Jan 2010 22:44:59 +0000

Just to add one more example which you would ignore, I have tried to
package OpenFire for Fedora
(http://www.igniterealtime.org/downloads/download-landing....
file=openfire/openfire_src_3_6_4.tar.gz, 48.81 MB) and after couple of days
of attempts I just gave up ... not only that the tarball contained JRE, it
also contained many many other packages (couple of database connectors,
couple of building tools like ant, and others ... did they really need
their own fork of ant, or did they just dump their working directory to the
tarball?).

When discussing this with the upstream programmers, and arguing with the
long established experience of Linux distributions that no package should
have if possible its own copy of system library for security and other
reasons, but I've got kicked out with totally clueless arguments that after
all packages will be better managed by them upstream (of course, no such
repository exists, and it has been couple of years).

Another example, I have really liked the idea of blueMarine
(http://bluemarine.tidalwave.it/). Aside from the fact that it never worked
on Fedora with openJDK (so much for TCK and "compile once, run
everywhere"), I again got the same mesh of all possible packages which
might be needed for it (30 MB; and again I don't care about the size
itself, but about its unmanageability and excessive complexity).

Could you actually show me one large Java project, which has proper tarball
with just the source code of the project itself, which has been cleaned up
by the endless work of the Linux packages (as Eclipse was)?

Callaway: Chromium: Why it isn't in Fedora yet as a proper package

ceplm — Thu, 07 Jan 2010 21:27:13 +0000

Really the number of apps is not the point ... complexity is. Try to
understand all packages required when you install some substantial program
(firefox, postgresql, eclipse-platform ...) and then compare them to
(comparably) trivial tiny apps available for iPhone. Just pure numbers are
absolutely meaningless.

Callaway: Chromium: Why it isn't in Fedora yet as a proper package

nim-nim — Fri, 11 Dec 2009 06:52:38 +0000

And I should have added in all fairness that ArgyllCMS's upstream tried to fixed some of those problems when notified, which is more that can be said about the average Java project.

Callaway: Chromium: Why it isn't in Fedora yet as a proper package

gwg — Fri, 11 Dec 2009 00:23:11 +0000

> In more than a decade of packaging I've only encountered once a non-java
> package which was as rotten to the core as the average java package is (argyllcms).

Nothing like slandering someone in passing, eh ?

Lets see, ArgyllCMS is about 6M of source (it's got a way
to go to get to the hundreds of meg of java apps mentioned),
and includes sources for exactly three libraries that are semi-standardized,
one of which is only used if the local system doesn't contain it (libtiff).
Being wider in scope than a mere Linux application (ie. it is cross platform
and runs on MSWindows and OS X too) makes for considerations that
go beyond what a particular Linux distro would like. In spite of
this, I've bent over backwards to accommodate peculiar requests
from various distributions (such as concerns about U.S. centric
patent issues, etc.). Daring to actually stand up to the
bullying of some Linux distro's seems to make me "rotten to the core"
it seems.

Actual users of Argyll appreciate that it installs and runs
on a wide variety of systems without any of the "dependency hell"
that can too often result from dependence on libraries that may or
may not be installed on a system, and may or may not be compatible,
and they also appreciate some degree of concern about whether the
software works correctly, rather than patching it for philosophical
reasons, and merely hoping that it still works.

Needless Forks

rahulsundaram — Thu, 10 Dec 2009 00:49:17 +0000

Yet, that is what is happening a lot more than before. The problem is not that distributions do not care about it (although the level will vary) but a lot of upstream projects have historically ignored this problem. Projects like GTK have been exceptions. A lot of base platform libraries are adopting a saner model (as defined in http://www106.pair.com/rhp/parallel.html) over time and distributions will naturally inherit this trait. The alternative is just sticking to a base version and backporting which has its own tradeoffs.

Not saying it's right, but..

rahulsundaram — Thu, 10 Dec 2009 00:44:34 +0000

RHEL also has a "stable kernel ABI" essentially because it is the same base kernel with backported patches till the end of the release.

Needless Forks

marcH — Thu, 10 Dec 2009 00:16:41 +0000

Even on an underlying OS that actually cares about stability you can still find some independent developers doing "the wrong thing". So guess how much chance there is of independent developers ever relying on system librairies provided by Linux distributions which do not care about stability at all? None.

Callaway: Chromium: Why it isn't in Fedora yet as a proper package

leoc — Wed, 09 Dec 2009 20:55:25 +0000

How many of those "apps" are anything other than a launcher for a web link? Also, as was pointed out in this item, the vast majority of available apps in the app store (as in 80% to 90%) are not really even maintained any longer. Considering the level of unprecedented hype that the iPhone and app store have received, you would expect the tail on this graph to be a little less flat.

Ignoring things like application size and complexity, duplication of function, actual level of use, end user quality, and the heavy hand of Apple censorship makes your argument about it somehow being a model to 'copy' specious at best. If any Linux distribution ever does consider adopting such a broken and anti-developer model, I'd keep away from it with a 20 foot pole.

Not saying it's right, but..

alankila — Wed, 09 Dec 2009 14:32:41 +0000

True, I suppose. Now if only such a thing also exposed a functional stable driver ABI for things like wlan cards and graphics drivers...

Needless Forks

mpr22 — Wed, 09 Dec 2009 09:56:12 +0000

It's amusing that you mention Windows on the backwards-compatibility score, when just about every Windows application I've ever installed appears to follow the "big ball of binary blobs" approach.

Needless Forks

marcH — Tue, 08 Dec 2009 17:14:26 +0000

> However, for development teams with enough resources to outrun upstream projects - to develop their own stuff and to see specific benefits faster than waiting for such things to appear upstream, if ever - it becomes tempting to fork the code and ignore the community.

And it is also tempting since it also isolates you from the opposite problem: inconsiderate upgrades causing regressions and lack of backward compatibility. Honestly, which distribution cares about backward compatibility from one release to another? Just for fun compare with Windows. Or even worse, think about Fedora who keeps issuing hundreds of non-security upgrades after the release. And this not just on the latest release but even for older "releases".

I realize backward compatibility is expensive while most Linux distributions are free. But still: if you do not care about external developers then you cannot ask them to behave and not fork.

(RedHat is off topic here since we are talking about a web browser)

Not saying it's right, but..

mpr22 — Tue, 08 Dec 2009 11:55:34 +0000

Doesn't the "pick a version of RHEL and stick with it" model basically fit the "Something that contains pile of software that tries not to change for a few years"?

Callaway: Chromium: Why it isn't in Fedora yet as a proper package

xkahn — Mon, 07 Dec 2009 18:26:12 +0000

I usually try not to reply to a thread until I've read all of it, but look at Alfresco. Here's a page where the Fedora project tried to create a package:

http://fedoraproject.org/wiki/Alfresco

You can see that Alfresco bundles a large number of JARs and that some of them have "_patched" in their name. And this is a package with a reasonably large company backing it!

Alfresco themselves mention this as a problem:

http://forums.alfresco.com/en/viewtopic.php?f=8&t=11744

There are some libraries were we have needed to make modifications to fix issues. Those are typically noted with a _patched. As Alfresco grows you never know when we may have to do this with something else.

We may be dependent on specific version. While it would be great to move to the latest and greatest, Alfresco may need more modification and testing to work with the latest and greatest

Not saying it's right, but..

alankila — Mon, 07 Dec 2009 14:56:55 +0000

My trollish response was just expressing a dissatisfication that there does not seem to be such a thing as a stable linux platform. Something that contains pile of software that tries not to change for a few years, and to which you can dump large code blobs like eclipse, or chromium, or whatever, without that distro's contributors going ballistic about how everything is not done according to their guidelines.

In short, I'd like to see a linux like windows: one which is as minimal as possible and where it is an endorsed practice to install 3rd party software, and such installed software exists, will work, and will continue to work for as long as humanly possible. If such a distro does decide to package proprietary software, it acts merely as glue and distributor channel, and doesn't spend years changing/breaking any of it, or removing useful blobs of functionality, or whatever.

Why do I think this way? Because I believe the open source community is not able to write drivers for all the new hardware, is not able to write decoders for all interesting codecs out there, is not able to keep things working even if someone does write such software. Proprietary code tends to bitrot at an alarming rate, and open source code bitrots and gets depreciated as well. I have had to throw out networking cards which no longer have working drivers, no matter they were once driven by open source code. Stability would be great. Rewriting the community to respect proprietary code, and the constraints such code is written in would be even better.

Not saying it's right, but..

rahulsundaram — Mon, 07 Dec 2009 04:16:51 +0000

Are you volunteering? Talk is cheap.

Not saying it's right, but..

alankila — Mon, 07 Dec 2009 03:58:53 +0000

Perhaps we just need different kind of distros.

Callaway: Chromium: Why it isn't in Fedora yet as a proper package

rahulsundaram — Mon, 07 Dec 2009 01:43:35 +0000

You continue to attribute claims that I did not make to me. I must ask you to stop doing that. I said, the most common problem with Java software is that they bundle copies of other Java software often with patches (to avoid dealing with dependencies). I did not say it is the most common problem in Fedora or Fedora 12.

A simple query on bugzilla doesn't return such information. Feel free to talk to package maintainers with some significant experience in maintaining packages for a large distribution and they would likely have noticed similar patterns. So would have the security teams of such distributions. You can also talk to folks involved with JPackage.

It was much more difficult a few years back

http://www.linuxjournal.com/article/7413

Red Hat's involvement with OpenJDK/IcedTea and other Java software has helped here and atleast some upstream projects have gotten better over a period of time as well, notably Eclipse. Some of it is a mismatch between tools. One effort to tackle the problem is at http://fedoraproject.org/wiki/KojiMavenSupport

Callaway: Chromium: Why it isn't in Fedora yet as a proper package

rahulsundaram — Mon, 07 Dec 2009 01:22:38 +0000

"Indeed. But you claimed that Java developers were rather special in that regard, afaict"

No. I did not. It is quite clear that it is not because this news story is not about a Java app. Java software is quite common and hence used often as an example but there are other offenders as well such as web apps. Java developers merely tend to make the problem worse because they continue to believe that they can ignore platform integration and just pass zip files holding large binary blogs of dependencies (with patches that have not been pushed to upstream) to users and JVM will take care of everything.

Unfortunately, it is not a simple problem space and their approach creates difficulties for integrators such as package maintainers. They have been ignoring this problem quite often although this appears to be changing over time.

Callaway: Chromium: Why it isn't in Fedora yet as a proper package

motk — Mon, 07 Dec 2009 00:07:18 +0000

I've used maven, and quite like it! I was refering to the Apple app store, not maven in this case.

Callaway: Chromium: Why it isn't in Fedora yet as a proper package

robilad — Sun, 06 Dec 2009 17:20:10 +0000

"It is common practise for Java software to bundled binary Jar files of other software."

Indeed. But you claimed that Java developers were rather special in that regard, afaict. You may be surprised to find out that bundling one's dependencies is not a practice limited to Java developers. If you look around the free software world carefully, you'll find that native cross-platform applications like Firefox embed their dependencies as well, and so on. This whole article is about the native application Chromium. No Java in there at all, afaict.

In the Firefox example, let me pick a dependency recently meantioned on LWN: jemalloc. It is the default malloc on FreeBSD, but you will have a hard time finding it packaged on Fedora. You'll find it's in the upstream sources, and if you look carefully, you'll find that Fedora even carries a local patch for jemalloc in Firefox: http://cvs.fedoraproject.org/viewvc/F-12/xulrunner/mozill... .

I'll have to leave it to you to decide whether that local change is good or bad engineering practice depending on the programming language background of the packager creating it ;) I tend to assume that Fedora packagers have at least as good reasons for the local changes they make to the dependencies of their project as well as anyone else has for their local changes in their projects.

Anyway, there is a bit of a difference from the perspective of a packager between bundling binary jars of one's dependencies coming from upstream projects (you communicate, strip & recursively replace dependencies with packaged versions), and your general claim that Java developers modify their bundled dependencies locally, and refuse to share their changes with the upstream claiming that they are too unique.

Callaway: Chromium: Why it isn't in Fedora yet as a proper package

nim-nim — Sun, 06 Dec 2009 16:55:05 +0000

> After some struggling,

Thank you for the some. Good way to paper over multiple recursive build and legal problems which seem to be the norm as soon as you lift a typical java bundle lid. Bugzilla is not a blog people only write a few lines here for hours of work.

Swinging the machete is highly unusual for non-Java packages. For Java packages, well, packagers are human too and there is a limit over which they give up or swing the machete. No one is going to spend multiple hours writing long bug reports when upstream does not care a nit (as evidenced by the dismal quality of their source release)

FYI I spend 4 years of my time packaging Java stuff at JPackage (non trivial packages such as tomcat, which have been copied almost all rpm-based distributions) and am still on their admin list, which is experience enough to have some idea of what the average Java source looks like. (I won't claim I was particularly good or inspired, except strangely enough there was no one better asking to take my place). I have been following different packaging efforts in this space for more than a little while. It takes 4 or 5 Java people to make 10% of the progress one person does naturally in other languages. There is such a legacy of forks, non-cooperative reinventing of the wheel, and other bad practices people always try to invent ways not to fix them because as soon as they realise the huge problem pile they want to forget it. Maybe SUN will manage to break the vicious circle with Java 1.7. It will have to release it first however. Also it needs to attain J2EE status before people start to take notice of it (ie it is years away). There is too much money in Java right now to make a purge easy, lesser languages at least have no illusion they must strive for the best to survive.

In more than a decade of packaging I've only encountered once a non-java package which was as rotten to the core as the average java package is (argyllcms).

And the problem never was technical (one could have done clean Java releases with make or ant a long time ago) but 100% cultural. JPackage antedates projects like maven yet maven developers quickly ignored all the early feedback JPackage gave them as soon as they realised it went contrary to the usual Java developper (bad) habits.

This is how bad the situation is.
Come back after your own 4 years of dedicated Java packaging before claiming others have no understanding of the Java state, or rejecting responsibility on one particular packager or distribution.

Callaway: Chromium: Why it isn't in Fedora yet as a proper package

robilad — Sun, 06 Dec 2009 15:47:45 +0000

My apologies for asking you to back something up you didn't literally say - you did not claim it was problem in the majority of cases, you said it was the 'most common one'. I'm curious how common it actually was for Fedora 12.
Is there a query for the Fedora bugzilla that lets me see those most common cases for Fedora 12?

Callaway: Chromium: Why it isn't in Fedora yet as a proper package

robilad — Sun, 06 Dec 2009 15:36:25 +0000

I looked at freemind because you told me it backed up your claims. I didn't pick a project at random to make you look bad.

There is only one review request for freemind in the Fedora bugzilla as far as I can tell. I'd appreciate a pointer to a review request that shows that the freemind upstream is shipping patched libraries and refusing to upstream their patches with the excuse that 'we're too unique', as you imply.

But maybe you meant to point me to another package, and made a typo, or something. Would you please be so kind to point me to the failed review request for Fedora 12 that backs up your sweeping claims about Java developers?

What is the ratio of the review requests failing for Fedora-specific reasons like freemind vs. those failing for the reasons you attribute to Java developers in general in Fedora 12? Since you make the claim that it's the majority of cases, it should be trivial for you to back that up, right?

Callaway: Chromium: Why it isn't in Fedora yet as a proper package

robilad — Sun, 06 Dec 2009 14:37:49 +0000

"I can't work out if you are trolling (badly), or are really failing to
understand what everyone is trying to tell you."

Thank you for your kind words, I appreciate your help in helping me understand what everyone is trying to tell me. If it helps, I think that your argument is sound - I just disagree that it in practice distribution developers really act very differently from Java developers.

Your basic claim here is that Java developers in general engage in activity #2, whereas other developers, in particular developers of distributions, don't. So, let's see if that claim is true.

In another thread, rahulsundaraman mentioned the troubles to package freemind in Fedora. I find that example slightly ironic, in light of the claim above:

https://bugzilla.redhat.com/show_bug.cgi?id=428413

After some struggling, the prospective packager decides to do some more radical changes on the upstream sources:

"Swinging the machete this way means to remove all export/import functionality from Freemind. However, the core functionality create, edit, open & save works fine, as does the browser applet. Plan to add some plugins later, if/when this package is approved."

None of the Fedora reviewers objects to the packaging technique of 'swinging the machete' to remove major functionality of the upstream application, or asks if the prospective packager coordinated that action with the upstream - after all, the upstream may prefer not to see users of its app struggling with a heavily locally patched version that lacks certain features, and see it more worthwhile to work on a long term solution instead.

Nothing in the bug report shows that such coordination took place, or that the first-time packager was encouraged by the reviewers to follow such basic rules of packaging upstream code.

Is that really a failure of the upstream to communicate with their upstreams, or is it a failure of the Fedora downstream to communicate their heavy, local patch attempts to the upstream?

From looking at the bug report, it seems like a case of the latter. No communication at all with the upstream is mentioned in the bug report, fwiw, and none of the Fedora reviewers seems to think that could be something worth pointing out in the bug report, which is rather surprising given the scope of the proposed machete swinging to get the application packaged.

So, I'd disagree, based on the attempt to package Freemind for Fedora, that Fedora packagers don't do #2.

Whether Java developers in general follow the same engineering practice of machete swinging, is an interesting question. From what I can see in the open source Java world today, the answer is 'not any more'. ;)

I have been following different packaging efforts in this space for a little while, so I know how hard it was to package Java libs & apps back in the last century. With the arrival of OpenJDK in distributions a year or so ago, this has become much simpler, due to the existence of a full, working implementation to build upon, and at the same time, because of the gradual move of many Java upstream projects towards Maven, Ivy and other forms of declarative dependency management.

Maven has been a thorny issue for many distributions, because it by default resolves the dependencies using repositories on the Internet. In the last year, both Fedora & Ubuntu have made significant progress on getting maven to be 'distribution-friendly', so that it can be used for building packages.

So I'd expect to see a lot more Java upstream packaging attemps in Fedora in the coming years - and that's why I'm interested in finding out whether the problems spot alludes to are indeed structural to the 'annoying' ways Java upstreams work today, as you imply, or are simply caused by a lack of technically competent communication between the Fedora downstream and the Java based projects that are being packaged. If the case is actually the latter, then the 'bah, stupid Java upstreams don't know anything about software development' mindset would seem to be harmful to improving Fedora in the long run.

Callaway: Chromium: Why it isn't in Fedora yet as a proper package

rahulsundaram — Sun, 06 Dec 2009 13:52:21 +0000

Wrong. Review requests are processed via bugzilla. Not in mailing lists. Looks like you are going to a great extend to avoid facing the fact that Java software has for a very long time sucky to package. It is common practise for Java software to bundled binary Jar files of other software. Go look at the source code for Eclipse or JBoss or ANY major Java software. Come back when you have done this analysis.

Callaway: Chromium: Why it isn't in Fedora yet as a proper package

rahulsundaram — Sun, 06 Dec 2009 13:39:49 +0000

Btw, there are several review failed review requests. You just managed to pick one. Feel free to research others and the long history of JPackage or Eclipse or any major Java software.

Spot maintains the largest number of packages in Fedora and nim-nim has been very involved with JPackage before. I have personal experiences which tell me the same thing. If you don't want to disagree with everyone's expertise, be my guest.

Callaway: Chromium: Why it isn't in Fedora yet as a proper package

robilad — Sun, 06 Dec 2009 13:12:50 +0000

"The practice is that given the same constraints as every one else, Java developers fare a *lot* worse than others and make life a *lot* harder for their distributors.

You can check this easily by asking integrators from *any* Linux or BSD distribution"

Ok. Let's take that claim seriously and check the fedora-devel-java mailing list. If the packagers were facing extremely uncooperative upstreams of the kind rahulsundaraman claims to exist, there surely should be no lack of traffic about it on that mailing list, right?

I have not found a single post on the fedora-devel-java mailing list in the last year complaining that a Java upstream is claiming to be too unique and refusing to upstream their own local patches further. If the claim about Java developers being exceptionally uncooperative in that regard is factual, it should be no problem for its makers to produce evidence on fedora-devel-java backing it, right?

Callaway: Chromium: Why it isn't in Fedora yet as a proper package

robilad — Sun, 06 Dec 2009 12:20:42 +0000

Thank you for your work on packaging in Fedora, and thank you for coming out with an example for your claim that Java developers claim that they are too unique, etc.

Rather then taking your claims at face value, I thought I'd see for myself. Not that I don't trust your authority, with you being a packager and all that, but I have not seen you post once to fedora-devel-java in the past 15 months, so I assume that is not your area of expertise. In particular, I can't find your name in the conversation in the Fedora bugzilla entry for freemind.

The last attempt in the Fedora package database that I can find is

https://bugzilla.redhat.com/show_bug.cgi?id=428413

It's a packaging attempt by Alex Leamas. A quick check on the freemind site confirms that he is not one of the freemind developers. That's not a good sign - the freemind source code tarball is larger then a megabyte, so understanding it in order to make significant modifications likely requires a significant investment in time.

In addition, Alec says:

"This is my first attempt to provide a package for Fedora...

Also, it's a java application. There is an obvious need for guidelines for java apps, hav'nt found any."

Attempting to package a large application in a domain where the distribution has no obviously findable guidelines as one's first package - what could possibly go wrong with that?

Then, after some initial work, some license issues are discovered by spot, and he says:

"Yeah, you are going to need to get upstream to resolve these license issues."

Now this could be the moment where the upstream shows uncooperative, and the oh so horrible ways of Java developers are unmasked. Amusingly enough, that's not what the bug says - it says nothing at all about the packager communicating with the upstream and reporting back how that went. So one has to search for it and finds an upstream developer say:

http://www.mail-archive.com/freemind-developer@lists.sour...

"I change the licence of my file soon and have a look at the others."

I tried hard to figure out how one could possibly take that to mean "we're too unique". I don't see it - to me that sounds like a Java upstream bending over backwards to help with licensing changes to ease the packaging into Fedora. Quite a different picture in reality then being painted here by spot & rahulsundaraman, apparently.

But, as I said, no word about that in the bug report.

So, why does the packaging attempt, unsurprisingly, eventually fail?

"file bindings.jar is the result of a compilation of a xml file which defines the interface. It might be impossible to get this compilation, involving JAXP API:s to work.

When rebuilding jaxme and running the compiler I run into problems since the source xml file contains constructs not supported by the jaxme xsd compiler. It might be possible to walk around this, but I don't know enough about the JAXP interfaces to do this, at least not now."

Translation to English: Because the prospective Fedora packager doesn't know enough about the software he's trying to package.

But that's not the only reason, there is also

"Even worse, current CVS sources shows that freemind now uses Sun's JAXB suite to handle this. It does support all constructs, but it is at best GPLv2 only. And it does not build for me, some kind of config problem."

JAXB is, of course, part of the Java SE 6 platform, so it's in IcedTea, OpenJDK 6, etc. It's dual licensed under CDDL 1.0 & GPLv2 with the Classpath Exception. No one of Fedora's licensing experts catches that mistake, and asks the prospective first-time packager to try using IcedTea or OpenJDK instead.

So it all predictably ends with:

"My first attempt to submit a package has, for now, failed.

The main reason is that recent code (after 0.0.9Beta15) has became heavy
dependent on Sun's JAXB reference implementation (https://jaxb.dev.java.net). This code has it's own set of dependencies, and could not reasonable be a part of this package due to both technical and legal reasons."

So, the legal reasons come down to Fedora's experts not bothering to check the first-time packager's assumptions about licensing of an upstream dependency and fix his mistake.

The technical reasons come down to the lack of prospective packager's technical prowess with the upstream codebase, and its dependencies. On a meta-level, attracting contributors for the jobs they don't have a chance of doing well is a failure in Fedora's recruiting & mentoring process.

Through the whole effort, the upstream project does not claim that they're too unique, apparently. There is nothing in the bug report indicating that the bundled libraries were patched and the upstream refused to send their patches further upstream, either, even though rahulsundaraman claims that is the most common issue.

So for someone familiar with Java development, the sweeping statements about Java developers made by rahulsundaraman & spot looks more like playing on a bias for the purpose of blame shifting to the upstream for inadequacies in Fedora's processes, recruiting & mentoring in the area of packaging Java applications.

What has happened since?

"Could this be reopened? The latest Freemind release candidates (I've tried 0.9.0-RC3 and RC4) work just fine with the OpenJDK VM supplied with Fedora 10 (java-1.6.0-openjdk-1.6.0.0-15.b14.fc10.i386"

"Please file a new review request and mark this bug as
a duplicate of the new one. "

No duplicate marked so far.

There has been a freemind package in Debian since 2004.

Callaway: Chromium: Why it isn't in Fedora yet as a proper package

rahulsundaram — Sat, 05 Dec 2009 07:31:11 +0000

FYI, I maintain several packages for Fedora and Java software has usually
been a severe pain point. Freemind for example is still not in Fedora after
several failed attempts because of problems like the one I noted. So yes,
it is personal experiences I am talking about. Whats your experience?

Not saying it's right, but..

dlang — Fri, 04 Dec 2009 18:26:31 +0000

pick your poison

developers have the right to make things hard for the distros, but if they choose to do so they don't have the right to complain that the distros don't include their program and include a competing program instead.

Not saying it's right, but..

alankila — Fri, 04 Dec 2009 18:12:06 +0000

If linux distributors want to mess with the things they package, then feel free to do so. I guess that's what they are going to do, with their guidelines and all. What irritates me is the whining that everyone else is not making your job easy for you.

Callaway: Chromium: Why it isn't in Fedora yet as a proper package

nim-nim — Fri, 04 Dec 2009 16:57:09 +0000

The theory is that the same pressures apply to all languages and they all suck equally.

The practice is that given the same constraints as every one else, Java developers fare a *lot* worse than others and make life a *lot* harder for their distributors.

You can check this easily by asking integrators from *any* Linux or BSD distribution

Callaway: Chromium: Why it isn't in Fedora yet as a proper package

nevyn — Fri, 04 Dec 2009 16:18:24 +0000

I can't work out if you are trolling (badly), or are really failing to
understand what everyone is trying to tell you. Being optimistic I will,
probably stupidly, try again:

1. Changing code from "your upstream" isn't great, but does have to be done
sometimes.

2. If you do #1 without contacting your upstream, or (less often) directly
against their wishes, that's much worse.

3. As a corollary to #2, if you are a significant portion of upstream then
it's much more defensible to change what you want (although not 100%
pristine, close enough).

4. As a corollary to #3, if you are just backporting patches from upstream
then it's basically 100% pristine by most sane measures.

...Java code (and Chromium) are doing #2, and "enterprise Linux" are #4 in
the vast majority of cases (the RHEL kernel has some notable exceptions
here, Eg. 4G/4G split, but they fall into #3). It's a matter of policy to
not do #2 in Fedora/RHEL (and AIUI, Debian, the SSL snafu was the exception
rather than the rule -- and even then they contacted upstream, just not
well), for the very reasons people are annoyed with Java/Chromium.

Callaway: Chromium: Why it isn't in Fedora yet as a proper package

robilad — Fri, 04 Dec 2009 15:37:27 +0000

"You continue to be disingenuous"

Well, thank you for your polite, respectful and informative words. You have eloquently convinced me, now I see that I was wrong all along.

Callaway: Chromium: Why it isn't in Fedora yet as a proper package

robilad — Fri, 04 Dec 2009 15:29:58 +0000

And I should point out that I'm interested in evidence to help me understand whether your translation of spot's words (thank you for doing that) is based on your actual, personal experiences packaging Java software for Fedora, or on a 'a friend of a friends once read on LWN ...' sort of experience ;)

Callaway: Chromium: Why it isn't in Fedora yet as a proper package

robilad — Fri, 04 Dec 2009 15:11:08 +0000

Well, I think that's the whole point - developers patch third party code because they have their own good reasons. Or so they believe. ;)

From the perspective of a platform provider, like a distribution, having control over what goes into the platform, and being able to tweak it to assemble one's platform built on own software along with various third party components into a coherent whole is a really good thing.

From the perspective of an application provider, being able to do the same is a good thing for pretty much the same reasons.

It's where the two worlds are forced to coexist that the conflicting interests collide. Blaming the conflicting interest on a particular programming language is quite short sighted, though - the ISVs struggling to get native code packaged for Linux across distributions are fighting with the same impedance mismatch between the interests of the platform provider and their own, and of course the regular 'language-specific dependency system sucks because it doesn't play well with my package manager' provides another set of evidence for that conflict - whether that's Ruby Gems, Python Eggs, or Maven.

Callaway: Chromium: Why it isn't in Fedora yet as a proper package

robilad — Fri, 04 Dec 2009 14:30:09 +0000

Actually - no - all that I've seen so far has been highly amusing ranting about the oh so horrible ways of Java developers and a few pointers to some applications having large downloads. Nothing that actually confirms the very specific claims about Zip files, "we are too unique" etc. you have made.

Please back those claims up with references.

Callaway: Chromium: Why it isn't in Fedora yet as a proper package

Cyberax — Fri, 04 Dec 2009 11:51:57 +0000

Have you _ever_ used Maven?

It's much more than a 'webdav' client. For example, Maven can be used to build application, run tests, bundle it and then upload to a repository. With source code attachments, if desired.

Your assertion is like saying that 'APT just downloads some files' or 'dpkg just unpacks archives'.