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
Attachment:
pgpnUAejJ1zJH.pgp
Description: PGP signature
