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]