Re: http://fedoraproject.org/wiki/TomCallaway/SecondaryArchitectures

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux