RFC: Split Package with Obsolete

Axel Thimm Axel.Thimm at ATrpms.net
Tue Aug 8 05:27:59 UTC 2006


On Mon, Aug 07, 2006 at 12:58:08PM +0200, Axel Thimm wrote:
> On Sun, Aug 06, 2006 at 08:25:03PM +0200, Thorsten Leemhuis wrote:
> > 2) add a this two lines to the new sub-pacakge:
> > Requires:       %{name} = %{version}-%{release}
> > Obsoletes:      mail-notification < 3.0-4

I just stumbled on another occasion about an rpmlint "error" which
would hit this idiom just the same:

E: ... obsolete-not-provided

I think this qualifies in general at the very most as a warning. Some
Obsoletes: like in this case are not implying that this package
provides the required functionality.

> > (see attached patch for the full context). This way yum will install the
> > new subpackage because it obsoletes the old main-package *and* yum will
> > install the new main-package because it's a dep of the new subpackage.
> 
> > This is somewhat hackish, but it's probably the most comfortable way for
> > the user.
> 
> Sounds sane enough. I would add a comment above the "hack" to identify
> which upgrade paths are affected (e.g. all FC <= 5), so when FC5 get's
> dropped from FL one day (in 18 months with FC9?) one can remove it
> again.
> 
> I think this is not really a hack, perhaps even the most elegant
> solution for such transparent splits. Maybe worth globally documenting
> somewhere in the wiki perhaps even the packaging guide?
-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-extras-list/attachments/20060808/45c4c91b/attachment.sig>


More information about the fedora-extras-list mailing list