Core Packages in Violation of the Fedora Naming Guidelines

[Michael Schwendt]

On Wed, 12 Jul 2006 09:00:24 +0200, Ralf Corsepius wrote:

> As a maintainer you see one spec-file per-distro in CVS.

Many packagers keep a single spec file for all dist releases. During
updates/upgrades they copy the modified spec to all branches. That's
called a mass-update.

On the contrary, there are packagers (also in Core) who maintain separate
branches with distinct spec files. Even during version upgrades, when they
upgrade an older branch to the same version as released for newer
branches, they do not want to lose old %changelog details and hence do not
want to copy spec files to multiple branches. Additionally, if they want
to express that the [source] package is for a specific dist release, it is
perfectly fine and appropriate when they hardcode a distribution tag in
the package release field.

> >  This avoids
> > mistakes during mass-updates to your package branches.
>
> How that? As a maintainer you have one spec-file per-distro, whether
> %{?dist} is present or not doesn't imply anything on whether a spec is
> buildable for a different distro.

%{?dist} is a variable, giving the false impression that the source
package may be valid for arbitrary dist releases and that filling it in
would be enough and that no other package updates are required. Even
worse, the dist tag enters the file names of the built packages.

> Using it, however has advantages for specs, which are designed to be
> shared across different distros.

That is an optional minor advantage, not a mandatory advantage. ;)

> > Using %{?dist} must not be mandatory. Hardcoding the value %{dist} would
> > expand to is justified in some cases.
>
> IMO, you are drawing invalid conclusions.

Fine. I can live with that. IMO it is short-sighted if packagers are not
permitted to hardcode a dist tag where appropriate.

Btw, the %{?dist} as we use it remains insufficient for CD/DVD
release-based distribution upgrades anyway. It gives a false impression of
upgrade-path safety. And unfortunately, RPM doesn't offer a DistRelease
Epoch which would fix the situation.