Bug 497646 - Upgrade path is broken
Upgrade path is broken
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: liberation-fonts (Show other bugs)
11
All Linux
low Severity urgent
: ---
: ---
Assigned To: Caius Chance
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks: F11Target
  Show dependency treegraph
 
Reported: 2009-04-25 11:07 EDT by Susi Lehtola
Modified: 2014-01-21 01:13 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-06-22 08:43:42 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
Patch to spec file to remove redundant provides and obsoletes (1.74 KB, patch)
2009-05-13 03:02 EDT, Susi Lehtola
no flags Details | Diff

  None (edit)
Description Susi Lehtola 2009-04-25 11:07:30 EDT
Liberation-fonts consists of a single package, liberation-fonts in Fedora 10. In F11 this package is missing, also nothing obsoletes or provides it.

This makes any packages that Requires: liberation-fonts not being able to install on a pure installation of F11, and liberation-fonts not updating from F10 to F11.
Comment 1 Nicolas Mailhot 2009-04-27 02:58:31 EDT
The liberation-fonts provides does not exist in Fedora 11. This is similar to what was done to other font packages. So you can not install a package that depends on liberation-fonts in F11, and you can not update a system to F11 if it includes a package depending on liberation-fonts not replaced by a new package with fixed requires

This was an intentional choice to force packagers to take into account the new F11 package layout.

However F11 itself should not include such a package, and the upgrade path works for pure Fedora packages, so it s NOTABUG
Comment 2 Susi Lehtola 2009-04-27 03:13:55 EDT
(In reply to comment #1)
> The liberation-fonts provides does not exist in Fedora 11. This is similar to
> what was done to other font packages. So you can not install a package that
> depends on liberation-fonts in F11, and you can not update a system to F11 if
> it includes a package depending on liberation-fonts not replaced by a new
> package with fixed requires
> 
> This was an intentional choice to force packagers to take into account the new
> F11 package layout.
> 
> However F11 itself should not include such a package, and the upgrade path
> works for pure Fedora packages, so it s NOTABUG  

I don't think that's a valid point: if you have a F10 system with some package requiring liberation-fonts, it will not be removed if the package that required it no longer requires it.

However, if the new F11 package requires the new liberation-fonts-subpackage, you will end up with a file clash, which is not what is supposed to happen.

"Forcing" other maintainers is not a good thing if it means that upgrades don't work automatically. At least for people wanting to yum upgrade this is a pain in the ass.

Now that F11 is going gold soon, I think you SHOULD put in the obsoletes, since every package that has already been built in F11 has taken the renamal into account-
Comment 3 Mamoru TASAKA 2009-04-27 03:24:28 EDT
(In reply to comment #1)
> The liberation-fonts provides does not exist in Fedora 11. This is similar to
> what was done to other font packages. So you can not install a package that
> depends on liberation-fonts in F11, and you can not update a system to F11 if
> it includes a package depending on liberation-fonts not replaced by a new
> package with fixed requires
> 
> This was an intentional choice to force packagers to take into account the new
> F11 package layout.
> 
> However F11 itself should not include such a package, and the upgrade path
> works for pure Fedora packages, so it s NOTABUG  

No. upgrading path from F-10 -> F-11 MUST be preserved.
This is not related to font packaging policy.
Comment 4 Susi Lehtola 2009-05-02 17:37:33 EDT
ping?

Spec file seems to contain some unnecessary stuff as well, e.g.

Conflicts:    liberation-fonts < 1.04.93-8
Obsoletes:    liberation-sans-fonts < 1.04.93-8
Provides:     liberation-sans-fonts = %{version}-%{release}

in the liberation-sans-fonts package. These should be removed. (The package automatically provides itself and obsoletes any older versions of itself. Conflicts shouldn't be ever used.)


The F10 package provides Mono, Sans and Serif fonts. I think the easiest way to fix the upgrade problem is to make liberation-fonts a metapackage that pulls in the font subpackages.
Comment 5 Caius Chance 2009-05-04 22:13:01 EDT
What'd you think, Nicolas?
Comment 6 Jens Petersen 2009-05-05 19:57:47 EDT
(In reply to comment #4)
> Conflicts:    liberation-fonts < 1.04.93-8
> Obsoletes:    liberation-sans-fonts < 1.04.93-8
> Provides:     liberation-sans-fonts = %{version}-%{release}
> in the liberation-sans-fonts package. These should be removed.

Agreed
Comment 7 Jens Petersen 2009-05-05 20:01:59 EDT
The upgrade path is liberation-fonts to liberation-fonts-compat which pulls in the new font subpackages.
Comment 8 Jens Petersen 2009-05-08 23:42:52 EDT
ping!
Comment 9 Nicolas Mailhot 2009-05-10 12:10:01 EDT
(In reply to comment #3)

> No. upgrading path from F-10 -> F-11 MUST be preserved.
> This is not related to font packaging policy.  

The upgrade path DOES work within Fedora. (see comment #7)

That third party packages fail is none of our problem. And a metapackage is certainly not needed. In fact a large part of the liberation spec ugly-ness is due to mixing in metapackage patterns. However even though this mixing makes it difficult to understand it should still work ok.


Anyway,

1. re:
Conflicts:    liberation-fonts < 1.04.93-8
⇒ request by the yum folks to workaround a groupupdate yum misbehaviour

2. re:
Obsoletes:    liberation-sans-fonts < 1.04.93-8
Provides:     liberation-sans-fonts = %{version}-%{release}
⇒ totally unnecessary, though harmless
Obsoletes:    liberation-fonts-sans < xxxx would have made sense if it had ever been pushed to users
Comment 10 Susi Lehtola 2009-05-10 12:23:10 EDT
http://fedoraproject.org/wiki/Packaging/NamingGuidelines#Renaming.2Freplacing_existing_packages

"If a package is being renamed without any functional changes, or is a compatible enough replacement to an existing package (where "enough" means that it includes only changes of magnitude that are commonly found in version upgrade changes), provide clean upgrade paths and compatibility with:

Provides: oldpackagename = $provEVR
Obsoletes: oldpackagename < $obsEVR"
Comment 11 Nicolas Mailhot 2009-05-10 12:53:32 EDT
The upgrade path is not broken so your point is moot. Fix your third-party package
Comment 12 Jens Petersen 2009-05-12 08:22:25 EDT
So let's fix this properly:

(In reply to comment #9)
> Obsoletes:    liberation-sans-fonts < 1.04.93-8
> Provides:     liberation-sans-fonts = %{version}-%{release}
> ⇒ totally unnecessary, though harmless
> Obsoletes:    liberation-fonts-sans < xxxx would have made sense if it had ever
> been pushed to users  

liberation-fonts-1.04.93-3.fc11 is the only build I see with liberation-fonts-sans.

I think we need just:

Obsoletes:    liberation-fonts-sans < 1.04.93-4

and similarly for mono and serif.
Comment 13 Susi Lehtola 2009-05-12 15:52:27 EDT
(In reply to comment #12)
> So let's fix this properly:
> 
> (In reply to comment #9)
> > Obsoletes:    liberation-sans-fonts < 1.04.93-8
> > Provides:     liberation-sans-fonts = %{version}-%{release}
> > ⇒ totally unnecessary, though harmless
> > Obsoletes:    liberation-fonts-sans < xxxx would have made sense if it had ever
> > been pushed to users  
> 
> liberation-fonts-1.04.93-3.fc11 is the only build I see with
> liberation-fonts-sans.
> 
> I think we need just:
> 
> Obsoletes:    liberation-fonts-sans < 1.04.93-4
> 
> and similarly for mono and serif.  

No, you don't need that since it's already automatically done by rpm. You can remove those lines altogether.
Comment 14 Jens Petersen 2009-05-13 00:16:58 EDT
(In reply to comment #13)
> No, you don't need that since it's already automatically done by rpm. You can
> remove those lines altogether.  

Huh?
Comment 15 Susi Lehtola 2009-05-13 03:02:29 EDT
Created attachment 343714 [details]
Patch to spec file to remove redundant provides and obsoletes

Patch to remove unnecessary Provides: and Obsoletes:, since those are automatically done by rpm.

Patch also modifies spec file so that liberation-fonts-common gets removed if no font packages are installed (currently if you install e.g. liberation-fonts-sans and then remove it, you are left with unnecessary liberation-fonts-common package on your system).
Comment 16 Nicolas Mailhot 2009-05-13 03:39:49 EDT
(In reply to comment #13)
> (In reply to comment #12)

> > I think we need just:
> > 
> > Obsoletes:    liberation-fonts-sans < 1.04.93-4
> > 
> > and similarly for mono and serif.  
> 
> No, you don't need that since it's already automatically done by rpm. You can
> remove those lines altogether.  

Read again.

As for your patch, I'm strongly against it.
1. you're introducing a common provides while making sure packagers had to take into account the different fonts was an explicit packaging goal
2. as far as I understand, you're relying on undocumented yum behaviour the yum developpers never committed to

If you want to change the way we package fonts, go the full public consultation => FPC review => FESCO review => months of QA like was done for F11
Comment 17 Susi Lehtola 2009-05-13 03:51:26 EDT
(In reply to comment #16)
> (In reply to comment #13)
> > (In reply to comment #12)
> 
> > > I think we need just:
> > > 
> > > Obsoletes:    liberation-fonts-sans < 1.04.93-4
> > > 
> > > and similarly for mono and serif.  
> > 
> > No, you don't need that since it's already automatically done by rpm. You can
> > remove those lines altogether.  
> 
> Read again.
> 
> As for your patch, I'm strongly against it.
> 1. you're introducing a common provides while making sure packagers had to take
> into account the different fonts was an explicit packaging goal
> 2. as far as I understand, you're relying on undocumented yum behaviour the yum
> developpers never committed to

1. What are you saying? I consider a support package that is not removed when the main package is removed a packaging mishap. %{fontname}-common should not exist in the system if there is no %{fontname}-fonts package installed.

2. What "undocumented yum behaviour" might you be referring to? The thing that a package automatically provides itself with its own version, and yum updates packages with newer versions?
Comment 18 Nicolas Mailhot 2009-05-13 04:19:32 EDT
(In reply to comment #17)

> 1. What are you saying? I consider a support package that is not removed when
> the main package is removed a packaging mishap. %{fontname}-common should not
> exist in the system if there is no %{fontname}-fonts package installed.

This is not a realistic expectation. Large parts of the distro violate this rule today and have for a long as Fedora and RHL existed.

> 2. What "undocumented yum behaviour" might you be referring to? The thing that
> a package automatically provides itself with its own version, and yum updates
> packages with newer versions?

You make different packages, that can be installed simultaneously, have the same provides. This has always been a case the dependency engines didn't handle very well. And you don't even have a strong reason to do so, your fix is at best cosmetic.
Comment 19 Susi Lehtola 2009-05-13 05:23:31 EDT
(In reply to comment #18)
> (In reply to comment #17)
> 
> > 1. What are you saying? I consider a support package that is not removed when
> > the main package is removed a packaging mishap. %{fontname}-common should not
> > exist in the system if there is no %{fontname}-fonts package installed.
> 
> This is not a realistic expectation. Large parts of the distro violate this
> rule today and have for a long as Fedora and RHL existed.

Status quo is not a valid argument IMHO.
 
> > 2. What "undocumented yum behaviour" might you be referring to? The thing that
> > a package automatically provides itself with its own version, and yum updates
> > packages with newer versions?
> 
> You make different packages, that can be installed simultaneously, have the
> same provides. This has always been a case the dependency engines didn't handle
> very well. And you don't even have a strong reason to do so, your fix is at
> best cosmetic.  

Okay; I've just seen the same sort of thing with other packages, e.g. xfig comes first to my mind.

You can do the dropping of the unnecessary Provides: and Obsoletes, though (even if it is just a cosmetic change).
Comment 20 Jens Petersen 2009-05-18 23:40:04 EDT
I dropped the provides, obsoletes and conflicts from the latest build in rawhide.
Comment 21 Jens Petersen 2009-05-18 23:41:35 EDT
liberation-fonts-1.04.93-11.fc12 to be clear.

(The conflicts were not wrong per se but unnecessary I think.)
Comment 22 Nicolas Mailhot 2009-05-19 04:39:36 EDT
IIRC the conflicts are needed to help yum in some obscure upgrade cases. If you want to drop them, do check with skvidal he's ok with it
Comment 23 Bug Zapper 2009-06-09 10:33:21 EDT
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle.
Changing version to '11'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 24 Jens Petersen 2009-06-21 22:23:33 EDT
(In reply to comment #22)
> IIRC the conflicts are needed to help yum in some obscure upgrade cases. If you
> want to drop them, do check with skvidal he's ok with it  

Ok if they are really needed there needs to be some documentation in the spec file explaining that - I didn't find any in the changelog either.
Comment 25 seth vidal 2009-06-22 00:27:39 EDT
1. did the package get renamed? If so - then there needs to be an obsoletes
2. What is the conflicts allowing?
Comment 26 Nicolas Mailhot 2009-06-22 03:50:57 EDT
(In reply to comment #25)
> 1. did the package get renamed? If so - then there needs to be an obsoletes

There are very few packages depending directly on font packages, and converting to font guidelines does not necessarily produce compatible packages. It replaces a lot of manual steps with automation, making new file location & naming predictible. However they do not necessarily match whatever the packager did manually before (and actually most often they don't).

So it's better not to pretend we provide the old package, to make deps on the old package break, and have packagers actually check the paths they use are all right. The main reason to add a dep on a font package is because an app does not use fontconfig and relies on exact file placement (which is argually a bug in the app since we've been converting to fontconfig for ~ 7 years now, but that's another problem)

> 2. What is the conflicts allowing?

There is not trace of it in bugzilla, because you gave advice over IRC, but IIRC they were added to the update pattern in the course of solving bug #474514. If you think it's not needed we'll be happy not to have to bother with it.
Comment 27 seth vidal 2009-06-22 08:23:15 EDT
Nicolas: was there a package in common use or in fedora that was renamed when it came into fedora? If so, then it needs to have an obsolete

and 474514 involves adding some obsoletes checking to part of yum. 


So far This isn't a yum bug this is a packaging issue. Just add the obsoletes.
Comment 28 Nicolas Mailhot 2009-06-22 08:43:42 EDT
(In reply to comment #27)
> Nicolas: was there a package in common use or in fedora that was renamed when
> it came into fedora? If so, then it needs to have an obsolete

This entry has derived massively from the original subject.

The original report was: Fedora upgrade path is broken because a Fedora package has been split, and a third-party package depended on it
=> NOTOURBUG, we've fixed our packages, and have no control of what third-parties do. If our upgrade path was broken for a package as massively deployed as liberation bugzilla would overflow with problem reports. Third-party packages should not expect Fedora font package names to live forever, and a release change is the right moment to break compat on this front

Then someone noticed the spec declared some explicit conflicts. As far as I know they were added to help yum during groupinstalls (in the course of resolving bug #474514). If you confirm they are not actually needed we'll remove them.
Comment 29 Jens Petersen 2009-06-22 22:02:25 EDT
Well I already removed the conflicts so it is more a case of "do we need to re-instate them?" ;)

I guess we can leave this for now or open another bug if I reintroduced a regression?
Comment 30 Jens Petersen 2009-06-22 22:08:39 EDT
(I am reminded of a good apt phrase: "Do what we document, document what we do." [perhaps by Paul Gampe])
Comment 31 Jens Petersen 2009-06-22 23:43:49 EDT
(In reply to comment #28)
> Then someone noticed the spec declared some explicit conflicts.

Well, I was mostly annoyed about the subpackages Obsoleting and Providing themselves:

 %package -n %{fontname}-sans-fonts
 Summary:      Sans-serif fonts to replace commonly used Microsoft Arial
 Group:        User Interface/X
 Requires:     %{fontname}-fonts-common = %{version}-%{release}
-Conflicts:    liberation-fonts < 1.04.93-8
-Obsoletes:    liberation-sans-fonts < 1.04.93-8
-Provides:     liberation-sans-fonts = %{version}-%{release}

but if the conflicts are needed it would be good to know why
and I can bring them back.

Note You need to log in before you can comment on or make changes to this bug.