On 10 Mar 2009 13:02:11 +0100, Jesús Guerrero wrote: > > 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. :)
By "unresolved" do you mean some automatic "resolving", causing real packaging problem? This is the only reason I may think of for trying some drastical things in order to fix it. For example, I discovered that the recent rpmbuild automatically insisted about this dependency, but not any more with one of my latest fixes. There are optional dependancies, like Perl/Tk (if one wants to use FvwmTabs) or xlock (to use fvwm-menu-xlock), but declaring that fvwm now depends on them for all users would contradict the developers intention. > > 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? Nothing in fvwm uses libxml. The fvwm package should not depend on libxslt either. But the build procedure may depend on it although this may possibly be moved even to the higher distribution step (just like the autotools requirement). This part about building html docs is not fully finished yet for the rpm/deb generation, there is still some decision to take. > 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. I spoke about the package in Fedora. > But this would be as silly as making it depend on feh, stalonetray > and every single wm* dockapp... a nonsense. So if this is a nonsense for you, then you may easily extend this to all handy, but optional modules and scripts in fvwm to see my point. Regards, Mikhael.
