[Fedora-packaging] Re: disttag

[Tom 'spot' Callaway]

On Sat, 2005-02-26 at 10:53 +0100, Axel Thimm wrote:

>why have the chrooted system do the guesswork, when the information is
>there at the rpmbuild level?
>
>rpmbuild --define 'disttag whatever' ...

Because I don't want to overcomplicate the buildsystem, or overuse the
disttag.

Let me try and clarify my thoughts here.

I think the "%{release}" field should be as simple as possible. The
original goal of the "%{release}" field was so that you could track the
difference between a package built yesterday, and today's new build. I
realize there are some cases in which people tried to overload the
"%{release} field.

These seem to be the three most common:

- Dealing with "pre-release" versions of packages, which screw up the
proper ordering of packages, making rpm think that "pre-release"
packages are infact newer than the final releases.

- Dealing with a single spec file that builds for multiple versions of
Fedora Core/RHL/RHEL.

- Repository tagging a package.

Now, I've looked at these three cases, and I've trying to document the
PackageNamingGuidelines to deal with the "pre-release" case (and its
still not entirely done, I'm going to move the "post-release" cases back
to %{version})

The %{disttag} macros are designed to take the conscious thought out of
the build process, so that maintainers in the "single spec" case can use
%{?disttag:.%{disttag}} in the "Release:" (and check against %{disttag}
in conditionals in the spec) and know that it will work. If you have to
pass the value at build time, you're opening the door for failure, and
for packagers to pollute the %{release} value.

I'm trying to avoid packages named like this:

logjam-4.4.1-44.0.3.17.FC4_spotwashere_WuTangClan3.i386.rpm

This is what I'm hoping for:

In the primary case (one spec per distro):
logjam-4.4.1-44.i386.rpm

In the pre-release case:
logjam-4.4.2-0.1.a.i386.rpm

In the multiple-distro/single-spec case:

logjam-4.4.1-44.2.fc4.i386.rpm

In the multiple-distro/single-spec and pre-release case:

logjam-4.4.2-0.1.a.2.fc4.i386.rpm

^^^ That's still ugly, but its the worst possible corner case.

The third reason to overload the %{release} field, repository tagging? I
don't see the point of doing it. Fedora Extras certainly doesn't need to
do it. It makes the package unnecessarily long and ugly, and it confuses
the upgrade progress. Is a package with a repotag of "Aargh" newer than
a repotag of "BoOoOo". 99% of users don't care at all where their
package comes from, as long as it works.

This is another reason I want %{disttag} to be defined automatically,
without anyone trying to --with a different value in there and
cluttering up the release field with noise.

>And if you can convince Jeff to patch up an automated suffix to the
>rpm tag you could keep the specfile totally clean from disttags,
>e.g. like they look like today.

This is a noble long term goal, but I'm trying to avoid patching rpm
unless absolutely necessary. The %{disttag} macros are backwards
compatible to at least Red Hat Linux 7.3 (is anyone really building for
older builds?).

Ideally, it would be a releasesuffix, very much like arch is today. RPM
would know about the proper ordering of distributions for upgrades, be
able to detect it from the system automatically, and users could
enable/disable the use of the releasesuffix disttag from their own
~/.rpmmacros.

But that's an extremely non-trivial process, and I'm not going to dump
it on Jeff.

>produces foo-1.2.3-4.rhel4.at.i386.rpm

Just to reiterate, I don't think the disttag should be used for repo
tagging. I consider the "mark of origin" unnecessary clutter.

In no way am I trying to belittle anyone who has created a repo, they
should be proud of their packages, but they shouldn't have to label them
like 0-day warez. If a user has edited their yum or apt config to
include it, then let that tool identify the origin of the package at
install time. I know for a fact that yum does this.

So, let me tell you my selfish utopian goal:

I want everyone packaging their open-source code in Fedora Extras. If
everyone with an open-source, US-friendly package was storing them in
Fedora Extras, we wouldn't even need repository tagging. It would
eliminate a LOT of repository mixing pain. Maintainers would still have
control over their package, within reasonable standards and practices.

Fedora Extras would become a one-stop shop for getting packages that are
not in Fedora Core. And I for one, would love to see us have RHEL
branches in Extras, but in the short-term, I want it to be easy for
someone to maintain their spec file and sources in Fedora Extras, and
build their RHEL packages from that for their own RHEL repository.

And I'm the unlucky guy who gets to try and make this happen.

Doesn't my utopia sound nice? The best part: We can do it. I'm not so
dumb to believe that there will never be other repositories besides
Fedora Extras, but the more we can centralize, the less duplication of
effort occurs. The more we centralize, the less confusing it is to the
Fedora end-user. The third party RPM repositories are doing good work, I
just want you to do it in Fedora Extras.

The first step to this is sane (and simple) standards and practices for
packaging.

Or put it this way: Tell me why you're not packaging in Fedora Extras
today. If its sponsorship concerns, I'll sponsor any 3rd party
repository maintainer right now. Just ask me.
If its packaging standards and guidelines, tell me where you're unhappy.
If its personal issues, lingering burn marks from flame wars in the
past, try to get over them. We're all doing this for the same reason: to
provide good quality addon packages for Fedora.

I didn't really mean to give a sermon like that, but it feels better to
have it out. :)

~spot
---
Tom "spot" Callaway: Red Hat Sales Engineer || GPG Fingerprint: 93054260
Fedora Extras Steering Committee Member (RPM Standards and Practices)
Aurora Linux Project Leader: http://auroralinux.org
Lemurs, llamas, and sparcs, oh my!