On Tuesday 17 February 2009 21:28:16 Matthew Woehlke wrote: > > well that is just the physical place. My point is that we don't want > > to be tied in with kde releases, and so I think it would be better > > if it is placed in say kdesupport/icons > > Actually, kdesupport would be fine with me also, though perhaps less so > with others (but if you get distros to update often, which is the > objective, it might not be so bad having to wait on distro updates, > especially if you don't write version dependency into the build system). > And it "feels" like about the right place. > > As I said, it's just that I would be less happy if I have to add Yet > Another Package to my build, and I can imagine others might feel > likewise. > > Also, on thinking about it, I don't expect version dependencies to work, > at least not if we try to go metapackage (i.e. 'requires: fd-icons' > instead of 'requires: oxygen-icons >= x.y.z'). The reason is that > different themes won't always add icons in the same order, so either the > version will be version of an fd.o spec where providing that means > *complete* conformance to that version (which, basically, means many > themes will either never provide the fd.o pseudo-package, or will lie > about it) or you'll wind up requiring 'firefox-icon'. This means either > a huge provides: list, or file dependencies, which I don't expect to go > over well. (Plus it will end with multiple themes installed, none of > which are "quite right".)
Yeah, I'm backing down a bit about the metapackage idea. In general it might be a good idea, but in practice it (as you illustrate) will be hard to make it work _______________________________________________ release-team mailing list [email protected] https://mail.kde.org/mailman/listinfo/release-team
