One day I was checking file-roller’s source code to see if it could use 7zip instead of unrar, for RAR files. As I was doing that, I noticed that all the file-roller’s USE flags could be in a neat package, like telepathy-connection-managers for example. So I collected the backend-related USE flags in file-roller, and created a new package app-arch/file-roller-backends, which has a little more options: IUSE="7z ace arj +bzip2 cab cpio +gzip iso jar lha lzip +lzma lzop rar rzip stf +tar zip zoo" I added a + for formats that most people would be surprised if they weren’t supported. I checked carefully the source code (it was actually version 2.30, but I think if anything changed, is for more supported formats, not less) to see which programs could be used, providing alternative RDEPENDs. If this ever makes it to the tree, you might consider adding in pkg_postinst a descriptive message about setting USE flags on file-roller-backends instead of file-roller, like the message for gst-plugins-meta. Reproducible: Always Steps to Reproduce:
Created attachment 263873 [details] New app-arch/file-roller-backends-2.32.0
Created attachment 263875 [details] Modified app-arch/file-roller-2.32.1 to RDEPEND on app-arch/file-roller-backends This has a new RDEPEND package, and no list of additional packages the user might want to install as backends.
Created attachment 263877 [details, diff] Patch for the above on current
I only noticed now several inaccuracies in my opening comment, due to too much time since I actually last used the official ebuild. (In reply to comment #0) > […] I noticed that all the file-roller’s USE flags […] I actually meant “…the packages mentioned at the end of file-roller’s installation”. > So I collected the backend-related USE flags in file-roller Ditto.
I disagree with having an ebuild simply to depend on some other packages, maybe we could add some more USE flags to file-roller ebuild to install needed tools (at least that USE flags that are already "global")
(In reply to comment #5) > I disagree with having an ebuild simply to depend on some other packages Why? I thought that was done pretty much whenever possible: media-plugins/gst-plugins-meta net-voip/telepathy-connection-managers x11-base/xorg-drivers plus the various GNOME, KDE and Xfce meta packages… It seems to me that whenever there’s a bunch of runtime-only dependencies, Gentoo’s way is to have a separate ebuild, instead of forcing users to recompile just for a single changed USE flag with *no* effect on the package itself. > maybe we could add some more USE flags to file-roller ebuild to install > needed tools Okay, but that’s exactly what I wanted to avoid, the reason I made a separate ebuild: there’s so many formats (and programs) file-roller can support that if one had to re-emerge file-roller for each new needed USE flag, that would be quite boring. I myself would have had to re-emerge it at least twice since I made this separated backends-ebuild (once was to add lzop, the other I can’t remember). Also, in case Gentoo ever gets PackageKit integration, this would make file-roller able to install backends much more rapidly (only wait for the backend to compile, not backend + file-roller). > (at least that USE flags that are already "global") Yeah, I tried to pick “good” names for the USE flags, but many just weren’t there, so I had to make them up. If support issues is what’s worrying you, I’m willing and able to maintain (proxy-maintain?) this new package, as well as file-roller itself, since I use it very often.
Will work on it in the future as talked with Gilles
(In reply to comment #7) > Will work on it in the future as talked with Gilles Mmm… since I don’t know what you and Gilles said, what work are you referring to? The USE flag names?
The splitting as you originally suggested
(In reply to comment #9) > The splitting as you originally suggested I thought I already took care of that… I can’t think of many different ways to do it.
@gnome, are you ok with using so many USE flags as suggested by Raffaello in that file-roller-backends ebuild?
(In reply to comment #11) > @gnome, are you ok with using so many USE flags as suggested by Raffaello in > that file-roller-backends ebuild? Yes. This seems to be an acceptable workaround until portage gets usable packagekit support.
(In reply to comment #12) > (In reply to comment #11) > > @gnome, are you ok with using so many USE flags as suggested by Raffaello in > > that file-roller-backends ebuild? > > Yes. This seems to be an acceptable workaround until portage gets usable > packagekit support. Personally I think this should be implemented if possible in file-roller-3 instead of 2.32 as I don't think there will be many more revisions for 2.32. Then, as I am still running with Gnome2, won't be able to take care of this just now, probably in the future.. :-/
There is a problem: See for example to "rar" -> it will RDEPEND on either p7zip or unrar... but unrar, if I remember correctly, is unable to create rar packages (only unpacks it) while installing app-arch/rar should be ok for both tasks Not sure how to handle this compressors/uncompressors options :-/
(In reply to comment #14) > There is a problem: > See for example to "rar" -> it will RDEPEND on either p7zip or unrar... but > unrar, if I remember correctly, is unable to create rar packages (only > unpacks it) while installing app-arch/rar should be ok for both tasks > > Not sure how to handle this compressors/uncompressors options :-/ Any idea about how to solve this problem? (this reminds me to similar problem with gst-plugins-meta but, in that case, we could RDEPEND in proper encoders when "encode" USE flag is set, but I see no flag for compressors)
*** Bug 440488 has been marked as a duplicate of this bug. ***
This looks to be more general than only file-roller, let's see if freedesktop maintainers agree with a meta ebuild to pull in needed deps
Why not base-system ?
(In reply to comment #18) > Why not base-system ? No idea, I was thinking in GUI tools only... if you think base-system should be involved also, fine (feel free to CC them or I will CC them if we agree)
(In reply to comment #18) > Why not base-system ? I don’t know right now if base-system is normally part of @system or it can be pulled in by any package in it, but I would avoid making a change that can cause 3-10 additional packages to be pulled in @system.
(In reply to comment #20) > (In reply to comment #18) > > Why not base-system ? > > I don’t know right now if base-system is normally part of @system or it can > be pulled in by any package in it, but I would avoid making a change that > can cause 3-10 additional packages to be pulled in @system. Nevermind, I thought I read sys-apps/baselayout :)
(In reply to comment #18) > Why not base-system ? Will CC them also then
call it 'app-arch/app-arch' just to mess with people i'm indifferent to the proposal at hand
I didn’t realize the name of such package was being discussed. How about app-arch/backends-meta ?
(In reply to comment #24) i really wouldn't mind calling it 'app-arch/app-arch'. but if you want something different, i'd suggest 'app-arch/archivers-meta'.
(In reply to comment #25) > (In reply to comment #24) > > i really wouldn't mind calling it 'app-arch/app-arch'. but if you want > something different, i'd suggest 'app-arch/archivers-meta'. That sounds even better, because even just ${PN} alone (“archivers-meta”) makes sense.