Gianluca Sforna wrote:
On 7/8/06, Mike A. Harris <mharris(a)mharris.ca> wrote:
> Note that similar strategy is used throughout all of the
> X.Org modular packaging, and packagers should always use
> a virtual dependency on modular X items if one exists
> already (ie: xdm, xfs, Xorg, Xnest, Xvfb, individual
> binaries present in various apps/utils packages, etc.).
> This helps to futureproof everything as much as possible,
> and while in a perfect world the packaging of things
> shouldn't really change much, nobody's planned on it
> changing and it has changed 4-5 times over the last
> 2-3 years, so using virtual provides/requires for this
> stuff now, helps to save everyone headaches in the
So, for example, right now I need to add a BR for the file
If one re-reads what I said above, you'll notice that I specified
'individual binaries', as in binary executables stored in
/usr/bin. For example, if for whatever reason some package
absolutely needs to execute "Xnest", it should have:
By depending on the virtual "Xnest", it ensures that if the
packaging of Xorg changes again in the future - as it has 2-3
times in the last 2-3 years, your package will survive the
packaging migration without needing any dependency updates,
as we will ensure that any new package that contains Xnest,
also has a "Provides: Xnest" in it.
Ditto for various other _binary_executables_, such as xdm,
xfs, Xorg, mkfontscale, mkfontdir, etc.
As far as any header files or other development files are
concerned, you _must_ individually require each individual
libXXXXXX-devel package that your software needs to compile
what BR: line should I use?
$ rpm -qf /usr/include/X11/StringDefs.h
Mike A. Harris * Open Source Advocate * http://mharris.ca