Re: Re: Tao u3/u4
Bogdan Costescu <Bogdan.Costescu-hEciA7+sKtudPOQpRHQ53DeJuz7u0hKX@public.gmane.org> Tue, 11 Jan 2005 18:04:41 +0100 (CET)
| Newsgroups | gmane.linux.tao.general |
|---|---|
| Message-ID | <Pine.LNX.4.44.0501101944040.2526-100000@kenzo.iwr.uni-heidelberg.de> |
On Fri, 7 Jan 2005, Remco Barendse wrote: > I really don't understand why the x86_64 release should be 3AS instead of > 1.0, neither do I understand why it is a problem to create a 3AS > repository nor is it burdensome for me to change $releasever with 1.0 to > get yum working. Probably another worthless opinion, but my thoughts are just the same. I would have actually suggested the last option; given the amount of work that the maintainers put into making the distribution, it's probably fair for the users to put up with these small annoyances and just make themselves such changes. > All I do know is that it is a big loss for the Tao project and Tao users. > I have been using Tao x86 and x86_64 with a lot of pleasure Same with me. I have actually chose Tao because both these archs which I use were available for the same distribution at the time when I needed them. They would provide a consistent "look" and the local mirroring would be simpler than hunting for 2 sets of updates. > I lack the knowledge by miles to do what Pasi did which means that I will > now have to move away from Tao for at least my x86_64 machines because I > am not sure whether I am able to always build the SRPMS the right way. I do have the knowledge, but I mostly lack the time... so the result is about the same :-( Furthermore, the value of a distribution is in the binary packages that one gets to install. This is the reason why RH values their binaries so much and doesn't make them available for free as they do with the sources. A binary package should provide the same files, dependencies, etc. on all machines where it is installed; rebuilding a SRPM makes the result depend on the building environment and as such is not as reliable as the binary RPM. If binary packages pass some QA done by maintainers and the same binary packages are installed on hundreds/thousands machines and behave well, people can then be confident that whenever they would install the same binary packages the result will be the same "good" behaviour. On the other hand, if the binary package is faulty, it's much more likely to affect more people and for the fix to be found fast. I have already mentioned this some weeks ago when I asked Pasi if he could make available his improved kernels. > I would like to thank both Pasi and David for their time and the support > I have been enjoying. Me too... -- Bogdan Costescu IWR - Interdisziplinaeres Zentrum fuer Wissenschaftliches Rechnen Universitaet Heidelberg, INF 368, D-69120 Heidelberg, GERMANY Telephone: +49 6221 54 8869, Telefax: +49 6221 54 8868 E-mail: Bogdan.Costescu-PDzUyZpvkMP/PDbm/[email protected]