On Fri, 2004-05-14 at 13:37, Nils Philippsen wrote: > On Fri, 2004-05-14 at 11:07, Axel Thimm 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. Fully agreed. > > 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. Neither in mine. IMO, what some people on this thread call "disttag" actually is the "root distribution's" repotag. What is confusing is the fact that RH/FC doesn't use an explicit "RH-repotag/disttag", while 3rd party packagers apply different and partially contradicting "disttag" conventions. Having this in mind, I also think, what 3rd party packagers actually need is a path into a tree of package sets originating from different repositories, e.g.: Fedora Core | +-> Fedora Extras -> Local FC+FE Add Ons +-> ATrpms -> Local FC+ATrpms Add Ons +-> .... IMO, the actual questions are: Is there a need to encode these paths into rpms and if yes how? IMO, yes, there is a need to encode these paths. Ralf
