On disttags (was: Choosing rpm-release for fc1 and fdr add-on rpms)

[Axel Thimm]

On Fri, May 14, 2004 at 01:37:45PM +0200, Nils Philippsen wrote:
> > Projects very near to Fedora Core (not "3rd party") like Fedora
> > Extras predecessor fedora.us, and fedoralegacy.org do require more
> > often to have common builds differentiating in the release built
> > against. So disttags are required.
> 
> Not necessarily. When discussing build systems, more than once the idea
> popped up that the maintainer shouldn't care about the release and that
> it would be autogenerated. These kind of build systems would be fed from
> a revision control system where you would put different distro-versions
> into different branches. How the build system generates release tags
> from that is a matter of discussion, but nothing the package maintainer
> should have to care for then.

Hm, I'd argue that the release tag is often quite important (the
buildid before the disttag), because it can be referred to from other
package in dependencies. E.g. when you move a file from one package to
another or have any special new releationship between packages than
need to Conflict/Require something based on the release tag.

That's another point where disttags are useful. If you fix your
package foo to foo-1.2.3-5.fc1 and foo-1.2.3-5.fc2, you can safely use
only

# foo up to 1.2.3-4 was buggy
Requires: foo >= 1.2.3-5

without mentining any disttags in the packages bar-6.7.8-9.fc1 and
bar-6.7.8-9.fc2, e.g. the disttag does not have to be mentioned in
dependencies. A scheme with manual coding of upgrade paths would
require different specfiles for bar-6.7.8-9.fc1 and bar-6.7.8-9.fc2 as
the dependencies would have to written differently.

What the buildsystem should do is add the disttags as suffixes to the
resulting rpm, so developers/packagers still only have to think about
the buildid and not the rest.

E.g. specfiles and src.rpm could stay as is in rawhide, the
buildsystem would adorne the release suffix as needed.

Later fedoralegacy in need for a security update can simply rebuild
the same package with the same buildid/specfile/src.rpm, but the
buildsystem would automatically have placed that package in a proper
upgrade path for future upgrading of the fedoralegacy build.

For example FC1 goes EOL and foo-1.2.3 has a security issue. FC3 has
foo-2.3.4-5 as foo-2.3.4-5.src.rpm and foo-2.3.4-5.fc3.i386.rpm. A
fedoralegacy packager tests whether the src.rpm rebuilds and works as
is on FC1, and if yes, simply pulls in the same source package, which
will yield foo-2.3.4-5.fc1.i386.rpm in fedoralegacy (or perhaps
fedoralegacy also uses a repotag id and this becomes
foo-2.3.4-5.fc1.lgcy.i386.rpm).

This minimizes maintainance of multiple releases at the cost of a
some little aesthetics.

(and to be honest all people are using repos like fedora.us,
freshrpms, ATrpms etc., each of which has its own interpretation of
the disharmonizing art of package naming and versioning obfuscation,
so users are hardened ;)

> > And as a community project you cannot keep out of scope "3rd party"
> > repos. They also support multiple releases of Red Hat and Fedora and
> > ths need disttags (not repotags!).
> 
> Not in my opinion.

What? Fedora is not a community project or 3rd party repos are not
within the community? :)

> > And really, disttags do not hurt at all. Aesthetics don't count in
> > packaging, otherwise we would package foo-1.2.3-4.el3.at.i386.rpm into
> > setup.exe.
> 
> Replacing ugliness with abomination here ;-)?

No, it is a psychological trick: After being shocked by uttermost
disgust disttags should look nicer, don't they? ;)
-- 
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-devel-list/attachments/20040514/4005c025/attachment.sig>