| Summary: | Create a meta ebuild to pull in needed packagers/unpackagers for file-roller, ark... | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Raffaello D. Di Napoli <rafdev> |
| Component: | [OLD] GNOME | Assignee: | Freedesktop bugs <freedesktop-bugs> |
| Status: | CONFIRMED --- | ||
| Severity: | enhancement | CC: | base-system |
| Priority: | High | Keywords: | Inclusion |
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
New app-arch/file-roller-backends-2.32.0
Modified app-arch/file-roller-2.32.1 to RDEPEND on app-arch/file-roller-backends Patch for the above on current |
||
|
Description
Raffaello D. Di Napoli
2011-02-26 05:17:41 UTC
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. |
