icon packaging

[C. Boemann]

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