https://bugzilla.novell.com/show_bug.cgi?id=377516 Andreas Jaeger <aj@novell.com> changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|aj@novell.com |ro@novell.com -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=377516 User suse@tlinx.org added comment https://bugzilla.novell.com/show_bug.cgi?id=377516#c2 L. A. Walsh <suse@tlinx.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|WONTFIX | --- Comment #2 from L. A. Walsh <suse@tlinx.org> 2008-06-02 14:29:12 MDT --- 'Abuse' another rpm tag? SuSE is already abusing the distribution tag -- because the distribution tag already has a defined and commonly understood meaning. For what you are wanting -- to track build conditions (architecture), the 'buildhost' field is there to allow vendors to include whatever they need as a 'where-it-was-built' info field. It wouldn't be abuse to use the buildhost field to include whatever information the vendor wishes to disclose about build conditions. This can be (and often is) a simple hostname -- where the vendor (or builder) knows all of the buildhost's configuration (including what software was loaded, what OS was running...and arch)...OR could be a buildhost name that reflects that information explicitly, like 'x86-64-buildhost1', 'ix86-buildhost2'...etc. As it is now, noarch or src packages are labeled for architecture specific releases. I.e. - By labeling the 'release' field with the architecture, this means (as is common in the industry), that the package is only for the vendor release on that specific architecture. Unless I am mistaken, I thought that SuSE releases were not architecture specific -- but were intended to be architecture 'neutral' across all the architectures that SuSE supports. Any packages that *are* architecture specific, are put into the 'arch' specific directories. But files in the 'noarch' and 'src' directories are designed to apply to all releases. If this isn't the case, and architectures of the build machines mean that the source packages have only been tested and verified on a particular architecture, then they need to be under arch-specific "noarch" and "src" directories -- which is something of an oxymoron. I'm not making this up -- if you want to record the build-arch, explicitly, it can be in the 'build-host' field, but normally, a vendor simply doesn't "confuse" the user by adding arch, OS, or hardware-specific information to the 'buildhost' name -- that information is usually kept and known internally -- that 'elflord' is running a 32-bit version of OSX, or 'dwarfish' is a PPC running 'Win2003' (joke) using cross-build tools. However, usually, the actual hardware configs of the build machines are usually identified by knowing the name of the host build machine. Appending the architecture to the hostname in the buildhostname field would be a proper and non-"abusive" way to make that information explicit, like buildhostname='elflord-32bit-osx' or buildmachinename='dwarfish-ppc-win2003' (though if your buildhost was running win2003, I sure wouldn't advertise it; better stick to just the arch part, 'dwarfish-ppc') :-) -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.