On Wed, 2007-07-11 at 02:40 -0400, Tom Lane wrote: > Manas Saksena <msaksena@xxxxxxxxxxx> writes: > > ... First, I assume that secondary arches can have a subset of packages > > from the main Fedora release. It might be a good idea to specifically > > say that. I dont know how to quantify it, but it also probably needs > > to be a reasonably large subset for it to make sense. > > The real bottom line here is very simple: if package A does not work > on arch B, how close will we hold package A's maintainer's toes to > the fire? If package A _never_ worked, then the answer is 'not at all', in almost all cases. If there's a package which doesn't work and has never worked, then it'll usually fall to the architecture team to fix it unless the package maintainer is feeling particularly conscientious. Mostly, that'll be because there's real porting work to be done. Occasionally I suppose it might be because the code is crap and has problems like endianness issues, assumptions about 'char' being signed, etc. -- but if we have competent maintainers and decent code that shouldn't _often_ be the case. If the offending package is a _core_ package, and actually _matters_, then the architecture team will have fixed it before they ever call for their arch to be included as a secondary architecture. If, on the other hand, the package _used_ to work and has now broken, then the package maintainer should care about that. It's actually quite likely to turn out to be a generic bug and not really arch-specific at all. If they conclude that it _is_ arch-specific, and that they really don't care about it, then they have the option of pushing the failed build anyway. > To my mind, most open-source packages should aspire to work on every > machine out there --- surely we all have a goal of world domination > in mind? I agree. To that end, I agree with Chris that it would be useful to keep at least one big-endian arch and one arch with unsigned char in the 'primary' set, to help keep maintainers honest and set the expectations. It's not as if it's that hard to admit defeat and an ExcludeArch if you really have to -- or even if you just can't be bothered. > But I can see that some folks might have more limited goals, > eg make game X work on hardware Y. If they publish their source code > then I surely don't want to exclude them from the open-source > community. And we don't. There are packages in Fedora now which have ExcludeArch: x86_64 because the packager doesn't understand the code well enough to fix the basic word size issues. I think it's unwise for us to prioritise quantity over quality to such an extent, > I don't know how to resolve these tensions. But for the most part > I think you should have a good excuse if you want to own a Fedora > package that doesn't run on anything under the sun. If your goal > does not include world domination, why not? A good excuse, and an ExcludeArch: bug filed. That's the policy we already have, and it works quite well. -- dwmw2 -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
