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

(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-

(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.

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.

What'd you think, Nicolas?

(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

The upgrade path is liberation-fonts to liberation-fonts-compat which pulls in the new font subpackages.

ping!

(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

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"

The upgrade path is not broken so your point is moot. Fix your third-party package

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.

(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.

(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?

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).

(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

(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?

(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.

(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).

I dropped the provides, obsoletes and conflicts from the latest build in rawhide.

liberation-fonts-1.04.93-11.fc12 to be clear.

(The conflicts were not wrong per se but unnecessary I think.)

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

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

(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.

1. did the package get renamed? If so - then there needs to be an obsoletes
2. What is the conflicts allowing?

(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.

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.

(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.

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?

(I am reminded of a good apt phrase: "Do what we document, document what we do." [perhaps by Paul Gampe])

(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.