El Mar, 10 de Marzo de 2009, 12:00, Mikhael Goikhman escribió: > On 10 Mar 2009 01:47:47 +0100, Jesús Guerrero wrote: > >> >> In the gentoo ebuild, Gtk.pm and *FvwmGtkDebug* are removed >> unconditionally since I cleaned up the whole think (for 2.5.25 I think, >> it's been long since), and no one has even complained about it. This is >> true for both the official ebuild for 2.5.26 and the unofficial cvs one. >> > > FvwmGtkDebug is not for the users, so this is not surprising. Still > it is interesting to ask what did you gain by removing 2 text files. > Especially the ones that were designed to work even without needed > dependencies by instructing users what should be done to make it > functional. Just dropping ebuild dependencies would be enough.
I see. Thanks for the explanation. :) I have no real experience with either of these. I did that in the ebuild just because I've seen that in other ebuilds. I agree that we gain nothing from removing to files. I did it partly because that seems to be the trend, and partly because I think that the perl module would not work without gtk-perl (which is not available in portage). I didn't know if it would exit gracefully or not so I took the easy choice which is just to remove it. I am only explaining my motivation, not saying that it's the right thing to do :) I don't care if it can work by manually installing whatever perl bindings package is needed. The gentoo policy ask from me that if a feature is enabled when building from an ebuild, all the required deps need to be resolved from the ebuild. Period. That's why there are separate DEPEND and >>RDEPEND<< (for runtime only stuff which would be the case). There's a solution, of course: to add the new package and maintain it along. But, as you said, this is free software, and if no one wants to do that, then the package is not into portage, and hence any fvwm feature depending in that package will need to be disabled. Packages with unresolved dependencies are either "fixed" or scheduled for removal, so the choice here is crystal clear for me. :) >> The rest of gtk1 support should work (never used it myself >> though) and is controlled via an USE flag, but I don't know about anyone >> using it either. So, I don't think that Gentoo users in general would >> care about you dropping gtk1 at all. > > Well, this is not new. Packagers of fvwm (with all honest respect to > them) always forced certain things on the users not intended by the fvwm > developers. :) I can't speak for the rest. I don't consider myself a packager, I just provide an easy way to compile the package (namely, an ebuild). It's up to the user what to do with that ebuild, what to enable and what to disable. That is, except for the missing bits I erase (I already explained why I do that above in this post). > One [real] distribution may decide that fvwm package should depend on > pyxdg, ImageMagick, libxml2 and other never intended things. But also > decide to exclude two text files that should not have dependencies. Now that you say it, the libxml2 dep on gentoo might be a candidate for removal. I guess that libxml2 is an indirect dep in the sense that libxslt will require it (and in turn, libxslt is required to build the fvwm documentation). So the ebuild should depend only in libxslt but not libxml2, can you confirm this, please? The other two packages you mentioned are not in the ebuild. And I can't think why would anyone add them as deps for fvwm, unless they are shipping a premade config for fvwm that uses these for something. But this would be as silly as making it depend on feh, stalonetray and every single wm* dockapp... a nonsense. > This is why we maintain the rpm and deb build procedures and encourage > users to build their own packages, not to be dependent on any external > decision and to get an installation similar to "make install". I don't > know whether the gentoo ebuild procedure should be included too. It may be > if for example the native package is made explicitely incompatible with > projects like fvwm-themes or wm-icons. :) In gentoo there's no premade config, the build is as vanilla as it can get and only influenced by the USEs that each user sets, which is like adding flags to ./configure. Using the Gentoo ebuild you can get a vanilla fvwm build just like the one you'd get by using ./configure, except that instead of passing option to configure you pass them via USE flags, and you don't need to care about dependencies. Additional patches, like the menu translucency ones are introduced via optional USE flags as well. fvwm-themes and crystal are as well into portage and well supported along with the icons and sound packages. Using ebuilds is just a convenient way to ./configure && make && whatever. Thanks again for all the feedback and regards. -- Jesús Guerrero
