rawhide report: 20080211 changes
Xavier Bachelot
xavier at bachelot.org
Fri Feb 15 12:50:53 UTC 2008
Michael Schwendt wrote:
> On Fri, 15 Feb 2008 12:15:40 +0100, Xavier Bachelot wrote:
>
>> Michael Schwendt wrote:
>>> On Thu, 14 Feb 2008 14:44:52 +0300, Peter Lemenkov wrote:
>>>
>>>> 2008/2/14, Xavier Bachelot:
>>>>>> perl-XML-Xerces-2.7.0_0-4.fc9.i386 requires libxerces-c.so.27
>>>>>> perl-XML-Xerces-2.7.0_0-4.fc9.x86_64 requires libxerces-c.so.27()(64bit)
>>>>>> perl-XML-Xerces-2.7.0_0-4.fc9.ppc requires libxerces-c.so.27
>>>>>> perl-XML-Xerces-2.7.0_0-4.fc9.ppc64 requires libxerces-c.so.27()(64bit)
>>>>> Is there a way to blacklist this package from the broken deps nag mail,
>>>>> or am I doomed to get it daily until xerces 3.0 is released ?
>>>> One possible solution is to provide compat-xerces-c-2.7.0.
>>> As the topic of "compat-" packages has come up elsewhere, too, recently,
>>> please think carefully whether to introduce either
>>>
>>> xerces-c27
>>>
>>> or:
>>>
>>> compat-xerces-c
>>>
>>> The compat- packages normally do not offer any -devel files you could use
>>> to (re)build other packages with. They are solely for binary compatibility
>>> with available packages, regardless of whether within Fedora or provided
>>> by a 3rd party. That's what the term "compatibility" means in this case.
>>> And we should not confuse the notion with multiple parallel installable
>>> versions of a library and its corresponding -devel packages. If you
>>> considered a compat-xerces-c-devel-2.7.0, that kind of defeats the purpose
>>> of compat- packages, and you could as well drop the "compat-" prefix from
>>> the package namespace and append the SONAME version to the base name, as
>>> in "xerces-c27" and "xerces-c27-devel".
>>>
>> Are there any guidelines or howto for building compat package ?
>> I'm not sure a compat package is of much use here, but it'll still be
>> something new to learn, so I'm willing to try.
>
> Create a spec as if you package a library as usual.
>
> Choose "compat-%{name}XY" as the basename for all packages, where XY
> is derived from the library version or the SONAME major version.
>
> Delete or %exclude any files that would go into the -devel package.
>
> Include only files needed at run-time.
>
> Make sure the binary rpms can coexist with all other packages versions
> of the library.
>
> If the compat- package is supposed to replace/rename a release of the
> library with a different package name, don't add any Obsoletes/Provides,
> because there is an sane upgrade path for the old library package namespace.
> Example: libfoo*-2.0 --> compat-libfoo2-2.0 + libfoo*-3.0
>
Thx Michael, I'll try asap.
I guess the package needs to go thru the review process, right ?
Regards,
Xavier
More information about the devel
mailing list