I just learned that Mozilla Firefox does support the jar protocol, so you can browse the contents of a jar file. I thought this would be great for ebuilds like e.g. java-sdk-docs, as it compresses a 291MB directory to a single 53MB file. Then e.g. jar:file:///usr/share/doc/java-sdk-docs-1.6.0/html.jar!/index.html could be used instead of file:///usr/share/doc/java-sdk-docs-1.6.0/index.html to access and browse this documentation. From a few test results, I believe that neither Opera nor Konqueror support this. So not every admin would want this, only one who knows that all documentation readers use Firefox (or probably Seamonkey). Also not every ebuild might be suited, as its HTML-documentation might link to some non-html files outside the html directory. But in both cases similar issues occur with compressed plaintext documentation, and still there is portage support for it. There are pagers that can't handle bzip2, and there are files that reference compressed files by name without specifying the correct compression suffix. I'm pretty sure I would want some form of enabling this, probably at my choice either globally or on a per-ebuild basis. I'm not sure how this can be achieved, though. Adding the functionality to some eclass that already does html handling should be straightforward, but adding an IUSE to each end every ebuild that uses dohtml or some such seems like a lot of change. Any suggestions?
(In reply to comment #0) > > I'm pretty sure I would want some form of enabling this, probably at my choice > either globally or on a per-ebuild basis. I'm not sure how this can be > achieved, though. Adding the functionality to some eclass that already does > html handling should be straightforward, but adding an IUSE to each end every > ebuild that uses dohtml or some such seems like a lot of change. Any > suggestions? > Well the IUSE can be added to the eclass.
(In reply to comment #1) > Well the IUSE can be added to the eclass. Would make sense if that eclass was used only by packages that provide this functionality. Originally I had thought of adding this function to the same eclass that provides dohtml, but now I found out that dohtml is not an eclass function but a portage script, so I guess a new eclass for this jar compression feature would be all right.
Stuff like this should not be done via IUSE. FEATURES maybe. Some questions: a) are we talking just about java ebuilds? Why not everything that has /usr/doc/$PF/html? b) .jar implies thinking about Java, but isn't it just zip? I doubt these jars have manifests and so on :) If we agree it's general case with html docs, then it's a package manager feature request, not eclass thing. BTW, you should be already able to do this via custom phase hooks.
(In reply to comment #3) > Stuff like this should not be done via IUSE. FEATURES maybe. maybe, yes. But is it possible to set FEATURES for individual packages? That's the main reason why I tend to vote against FEATURES or an analogon to PORTAGE_COMPRESS. Main argument for having this per-package is that some packages might be accessed by users who can't cope with jar, while others might not and are large enough to warrant the effort of compressing them. > a) are we talking just about java ebuilds? Why not everything that has > /usr/doc/$PF/html? I didn't file this as a java-specific bug, and I certainly had other packages in mind as well. Perhaps jakub was a bit quick assigning this to java after reading jar in the Summary. > b) .jar implies thinking about Java, but isn't it just zip? I doubt these jars > have manifests and so on :) Well, the jar: protocol is a Java invention. Right now this works perfectly well with the file itself being zip, not jar. I'd have chosen the jar extension because it is easy to associate the jar extension with the jar protocol in people's minds. And some day there might be some manifest entry that affects handling of the jar protocol, in which case we might just want it. As the manifest is no serious overhead, the main reason to use ZIP might be to avoid a dependency on jar. > If we agree it's general case with html docs, then it's a package manager > feature request, not eclass thing. Yes, I guess it would be. Should this be switched to Portage Development then? > BTW, you should be already able to do this via custom phase hooks. Is there some documentation on this?
If packages want to do this based on a USE flag then I think that's fine. I don't think we want to add support for this directly to portage though. I imagine that someday all filesystems will support transparent compression and putting stuff in a jar file to save space will be unnecessary. I look at PORTAGE_COMPRESS as something that will also become unnecessary in the same way. We're already prepared for that by allowing you set PORTAGE_COMPRESS="" to disable compression.
(In reply to comment #5) > If packages want to do this based on a USE flag then I think that's fine. I > don't think we want to add support for this directly to portage though. I guess in that case we are back to an eclass providing the functions and ebuilds inheriting it to use it. > I imagine that someday all filesystems will support transparent compression > and putting stuff in a jar file to save space will be unnecessary. I agree that this would seem the best solution, but a can't see it coming in the near future. Ext4 still has no transparent compression, e2compr looks pretty abandoned, Reiser4 isn't included in official kernel releases, ZFS has troubles due to licensing issues, so out of all the filesystem zoo, this leaves me with zero kernel mode filesystems supporting transparent compression that I know of. Although there seem to be several compressed filesystems using fuse, I couldn't find an ebuild for any of them. I assume that Mozilla will get their applications to transparently decode any gz files <https://bugzilla.mozilla.org/show_bug.cgi?id=52282> way before the majority of filesystems supports transparent compression.
In the interests of not over stretching the Java team's resources any further, I suggest this should be closed. Here are some reasons: * Hard disk space is cheap these days. * Most packages don't have that many docs. * Few people even install the docs anyway. * Many of these docs, including the Java SDK, are readily available online.
Also, btrfs. ;)
Agreed. Further, as Caster pointed out, it's not really a feature that should be handled by Java eclasses but rather the package manager. Zac's comment back in 2007 was almost prophetic: we're in 2015 now and many FS support compression right out of the box: brtfs, ext4, ZFS.. Pick your choice. Closing this bug.
