[CentOS-devel] progress?

You can read this interview with Karanbir Singh:
http://www.oneopensource.it/03/02/2011/centos-6-interview-with-karanbir-singh/

In short:
- There is about 2-3 weeks more before 6 is released.
- CentOS 5.6 should be available for download any day now.

William L. Sebok wrote:

Since that interview was about two weeks ago, I don't think it's
unreasonable to have a brief status update at this point.

One is not expected to criticize on this list. All is well. Don't ask any
uncomfortable questions please ! It's normal for a RHEL rebuild to be
months behind the original. It has never been different for years. Either
shut up or pay for the real thing. The developers are doing the best they
can. Again all is well. Don't believe the non-believers.

Are you sure, this answer was ok?

I can't see any criticism, not in Mathews comment and not in the
original question. And even if, a fair comment should be ok, or?

And if you really think, the question is uncomfortable, don't answer.
But don't tell people, it's not allowed to ask questions ...

You are such a baby Dag.

If after so many years we still have the same issues, and the same threads
and arguments come up, including the promise to fix it after the release
gets out, but it never does, then yes, I become cynical.

It's been almost 2 years I left the CentOS team because I couldn't defend
the CentOS project anymore. The only thing solved was the ownership of
the CentOS name and domains, but all the other problems regarding code
transparency, trust-issues, missing or delayed updates, governance,
adding more people for redundancy, where the considerable ad income is
going, etc...

But I am preaching to the wrong choir, because you obviously know all
this.

http://dag.wieers.com/blog/leaving-centos-team-not-centos-community

At least with your involvement I am confident CentOS 4.9 will not be as
late as CentOS 4.8 was. (And this time I am not being cynical)

Have you attempted the same involvement with SL? Or considered building
a non-scientific respin of their version? (Basically backing out their
changes...). Given the economic environment, maybe it would be good if
they had some volunteer backup.

Hi Les,

I recently became a dad, am renovating a house, am involved in a few Open
Source projects already, so the little time I have left I would like to
spend wisely ;-) Although I would support any initiative to bring more
competition into the RHEL rebuild market.

My opinion has always been that more competition is good for CentOS and
for its users, compare the current situation with when Whitebox and Tao
Linux were still around and you could feel the positive influence of the
competition (the race to be the first to release was one of them).

That's why more transparency from CentOS regarding to buildtools, changes
and processes (including an open QA process) would be a much better
approach in the long run for everyone involved than a closed and protected
process with less than a handful of people at the center and the large
community in the dark.

Although I do understand that some people prefer to keep the control and
power over things, I just do not agree with it.

IMHO Dag should _consider_ what centos.alt.ru has done and either vet
them or do the same thing if they can't be vetted. There's a need for
current BIND, et al and RH's policy of backporting takes time and puts
perhaps millions of systems at risk.

SL could have been named "US Government Linux"; there's nothing
"scientific" about sl-base and sl-security. It plays well in the same
environments RH and CentOS play well in, of course, because of the
charter.

kind regards/ldv/vaden at texoma.net

<quote from top management of Internet2 security>
It's fundamentally wrong for RedHat to attempt to backport security patches
for such a fundamental service. I'd cuss a blue streak about this point, in
fact, except that I don't want to trigger the anti-cuss features at
Dr. Vaughn's place of employment.
</quote from manager of Internet2 security>

That's very much a separate issue, and a question of whether you prefer
old bugs to new ones. Unless you think there are no new bugs.

New bugs are arguably more difficult to exploit than well known old
bugs and IMHO the OSS community, in general, moves closer to a
complete and correct solution with each release.

You keep quoting this, but, it seems to me Red Hat has done very well in the market at a time in which the market was difficult. They can't be doing to many things that are 'fundamentally wrong' or they'd go out of business (since they aren't a monopoly). Details, man, details.

However, the CentOS list is the wrong place to address this; the stated goal of the core CentOS repositories (this excludes CentOSPlus) is to be as close to upstream as is possible in building from the source; bugs and all. Address the bug upstream; it will then come downstream. That is and has been the CentOS credo pretty much as long as there has been a CentOS, as far as I can recall.

As a further comment, it is not easy to get this close to the upstream at the binary level. Things are better than they used to be back in the days of beehive and highly customized specialized buildhosts (I could find my archived message from Jeff Johnson about it, and I probably could share it here since it's been over ten years, but I have more important things to do after I'm finished with lunch).

But things are not perfect, and Red Hat does not make public the complete specs on its buildsystems. Like I say, it is better now than in the good old days, thanks in no small part to the Fedora project's open infrastructure, but there are still niggles to do to get things to build.

Troy has documented on the SL list about some of those niggles; I've been reading the release notes, and they are revealing about the process, and about some fundamental differences between SL and CentOS, both the distributions and the projects. Anyone curious about those differences, read through the archives of all the lists and see them for yourself; I'm not going to summarize here. Suffice to say that I don't think either approach is the One True Way to an EL rebuild; they are just different.

At one time I thought they should join forces, but even as talented as all the folks involved are, it wouldn't be the greatest of ideas; in a way, thanks to how open the processes of both distributions are (yes, the CentOS process is more open than it could be!), they already have joined forces, just as sovereign allies, instead of parts of one big project.

Johnny has posted a link to the buildsystem 'things' for C3,4,and 5; 6 isn't up there, probably because it's not finalized.

I was there in the old days of waiting on a new RHL release; this process is scads more open than the process then was, that is for sure.

In a truly open system, you don't need to 'join forces' to take
advantage of each others' work. The version control system will tell
you everything you might need to know, and the fact that it is open
means that permission to use it is implicit.

Perhaps the expression 'join forces' isn't quite right.

The idea wasn't so much sharing information as sharing infrastructure; thus the 'forces' aspect of the 'join' since 'forces' implies infrastructure. At least that was my intent, and what I erroneously thought to be a good idea, as then you can avoid duplication of effort in the infrastructure.

Since the hard work of integrating the distribution has already been done by Red Hat, and the result of that work is open in terms of the source for the distributed binary RPMs, the work isn't as hard as what the Fedora project or the Debian project does; but it isn't trivial or even easy, either, and much of the effort beyond trademark purging and replacement involves the build and distribution infrastructure.

Nobody said it was trivial or easy. No major software project is. But
the open ones put all their tools in a version control system that
anyone can access and duplicate. And the successful open ones find that
some of the people who do access and duplicate their work improve on it
and make their improvements available. Is anything like that happening
here?

But the VERSION CONTROL SYSTEM would need to be implemented BY upstream
not us.

Our stated goal is to NOT change anything that we don't have to change.
We ONLY make changes to the packages as required to remove trademarks
... we add NO CHANGES to fix the packages.

It is our goal to NOT HAVE ANY CHANGES.

Therefore a VCS at the package level for our projects is worthless
(except for the packages that we have to change to remove trademarks).

That is what no one is understanding here.

We do NOT change the packages (the SRPMS), therefore there is nothing
inside the packages to track. If you have the SRPM, you have the source
code that would get imported into the VCS ... it would then also be
rebuilt exactly like it was to submit it to the build system.

For packages that are not changed at all (the VAST MAJORITY in the case
of CentOS), this splitting of SRPMS into a VCS and then reassembly from
the VCS into an SRPM adds nothing to the overall process. In fact, it
only adds a potential spot to do unneeded actions that might introduce
errors into the packages on reassembly.

So, this VCS at the CentOS level is extra work for us with no added
benefit to producing packages.

The vast majority of the time, we are working directly with SRPMS, and
not a VCS.

Something else i want to point out here is that IF you need to adjust a
build root for a package for version x.y.z-1 ... when x.y.z-2 comes out,
it may or may not need that same change. And in fact, we try building
it first with NO changes in the build root to see if it will build, if
it does not then we would look at what is in (or what is extra in) the
compare process and add or remove things to get the correct linking.

There is no magic secret sauce or magic VCS here to be kept over time.
It is brute force build, compare, adjust, build. It is good only for
the one iteration for which it is performed. The next time a new
package is built, we do it in a virgin way to try and reproduce it
exactly as the SRPM requires.

It is no harder than build it in mock ... check it ... manually modify
the build root with some commands ... if required (if the package fails
the compare).

You guys act like we are doing magic here, we are not.

How do you track the work you do, reproduce it across architectures, and
duplicate it to spread the load over multiple machines?
That sounds exactly like a situation where having more people involved could
help, given the ability to share the state of current work.
You really aren't doing those changes by retyping the command lines on every
machine involved with no automated way to reproduce it or history of what you've
done, are you?

I don't know how CentOS the project does this; and that's ok.

I do know how Fedora does it, and it's called koji. And apparently RHEL6 was created with koji. Koji was built from the ground up to do this, and do it on a large scale.

For all I know Johnny and Karanbir and whoever else is doing buildsystem work for CentOS may be using koji; but my gut feel is that if they're not using it now it's too late in this cycle to start with it.

Perhaps in the future; and perhaps not, that's up to the folk doing the actual work of producing the distribution to decide. Not my decision, that much is for sure. Now if I wanted to produce my own dist (LOOSE; Lamar Owen's Operating System - Enterprise) it would be up to me. But this is CentOS, and it isn't up to me. I shouldn't try to be a backseat driver, IOW.

Hi,
We dont use Koji, there are no plans to use koji or anything like that.
We have very basic requirements from the buildsystem and we have a lot
of requirements on the testing side of things. Going with a basic
process that can work with srpms and work with automated testing at the
other end is what was decided. Were sticking with that for the near future.
the idea of 'version control' is interesting, we publish ( just as we
work with ) complete, tested srpms as the code-component because it
helps retain some level of sanity ( even if the idea of sanity is insane
in cases with builddep's are no longer relevant etc ). However if people
want to work with a git like repo, I created and pulled in the el6
codebase into git repo's, hosted at https://nazar.karan.org/cgit/ -
thats available as a purely side effect resource that people want to
look at, its not what we work with within centos.

- KB

Whew. I understand this, for sure; but I think there is some cross-communication misunderstandings here.

What I think most people are asking about is not the packages that are being built, and a VCS for the packages (if that's what they are wanting), well, I agree 100% that that is useless, since, as stated, to goal is the rebuild the completely unchanged source RPM and get the binary equivalent RPM out the backend. The SRPMS for the upstream components are already publicly visible at ftp.redhat.com.

What I think folks are most interested in, and I know this is my case, is the versioning of the packages and changes (custom scripts, etc) to any packages on the buildhost that is doing the mock build itself.

It's kindof like making sourdough bread (which I've done, using native yeast starter); the same set of ingredients, and the sourdough recipe is a well-known recipe, and pretty consistent from location to location, but yet the same ingredients using the same exact recipe can produce different results; it's all in the particular native yeast used for the starter, and the techniques used to get the starter started. That's why San Francisco sourdough bread tastes different from Western North Carolina sourdough bread; different yeasts.

The upstream SRPMS are the ingredients, mock is the recipe; but what went into the starter?

And, yes, sourdough starters are closely guarded secrets at bakeries that have unique products; similar is true for other yeast-driven ferments, including various alcoholic beverages made from fermented starches of various kinds. Which is why you can't make true scotch whisky anywhere but Scotland; it's all in the yeast, which is native.

That's the part of the process that isn't externally open as far as I can tell. We have quite a bit of scattered documentation on the buildsystem, including mock configs, your scripts you posted a while back, etc. But the versioning of the buildhost (which, in theory shouldn't matter but in practice it does, especially for certain architectures like UltraSPARC) isn't well documented. At least I've not run across it; which is not the same thing as saying that it doesn't exist: it's just saying that I've not yet found it.

To me, a simple 'rpm -qa|sort' output from the buildhost itself would answer a lot of my questions. I certainly would like to see that output for the IA64 buildhost, and for the last buildhost used for that one alpha SPARC build, as I would like to do those myself (getting C6 on UltraSPARC would be one of my end goals; there is a semi-usable F12-beta for SPARC, even though it's pretty broken for development purposes, meaning that the koji instance on the builder couldn't have been self-hosting and must be running something 'special').

But without knowing the packages and scripts on the buildhost and external to the SRPM repository to build I don't even know where to start, since I know a buildhost on SPARC requires some deep magic to set up (64-bit kernel but 32-bit userland; the buildhost has to be able to build a 64-bit kernel, and that isn't the easiest of tasks when the whole of userland is 32-bits, which makes sense pretty much only on SPARC, since 64-bit has no performance advantages on SPARC, just memory size advantages). I had a mutt setup on our E6500 at one time that began with Aurora 1.0 and went from there, using yum upgrades..... and replicating it would be a major undertaking. But that was the only SPARC build that I had here that would successfully build a kernel package set.

So I'm off to investigate the Fedora buildhost documentation that I can find and go from there. (pointer for those who want to see 'square 1' for such:
http://fedoraproject.org/wiki/Koji/ServerHowTo ) And this is really overkill infrastructure for a buildhost used for special purposes, I know, but at least it's a documented large-scale distributed buildsystem, and perhaps the key to understanding the whole thing resides somewhere in the reams of information out there)....and in no way am I implying that CentOS uses koji, just that a closely related project does (since Fedora is somewhat the upstream for RHEL).

And, of course, getting an IA64 C6 (which might or might not be possible) would be something I'd love to try out, and is something I would want to do myself and not bother anyone else with; and if the results were something other people would want, then we could look at that when/if that arose.

And while I may very well have missed what others are interested in, I'm interested mostly in the buildhost magic, and there is magic at the buildhost level in any rebuild. Even if the magic is not automated...... And I'm not at all interested in 'competing' with the CentOS project; I don't have the bandwidth, for one, even if I do have the storage.

But I certainly reserve the right to be wrong, on all counts.

I completely agree. I am interested in duplicating it so I can learn
more about the process, and through that perhaps be able to contribute
to the project. I think what would be ideal would be something like a
kickstart plus a puppet configuration for the buildhost, or at least a
wiki page documenting the exact steps for setting up a buildhost.

Steve

Hi,
These sort of questions come from the FUD created by the silly people.
In order to convert a source package to a binary package, you need to
hit rpmbuild at some stage or the other, the environment it churns in
can impact the result and these days convention in the
rhel/fedora/centos areas is to use mock and a defined common buildroot.

The idea of magic juice used by CentOS is not only stupid its also what
leads you into believing a lot of the other crap that these people
shovel out.

- KB

I was basing my statement on what Johnny had said. He stated that the
reason it takes so long to do rebuilds is because the build environment
for some packages is unknown, and it takes some guesswork to figure out
whether it was built on RHEL 5, Fedora, or whatever.

Steve Meyers

and so ?

whats stopping you from trying to get through that stuff like others
have done ? Timo / Farkas etc have been vocal and been busy in the
bugzilla.r.c for and with just this sort of an effort.

Maybe I just fail to see what your point is.

- KB

A member of the "information wants to be free club" offers this quote from Troy:

<quote>
p.s. Really, we have no "top secret" stuff. High Energy Physics labs
are very open and willing to share.
</quote>

Hi
You will find that its only you who really comes up with these things -
and since the 6.0 was announced upstream this is the third time you have
decided to start throwing marbles around a process you neither
understand nor want to.

I've read through most of this thread and its all just random stuff
recycled over and over with zero real value add. You seem to have
something in your mind as to how a process might work, and are
completely unable to comprehend any deviations from there. I am no sure
if there is any other way to put this across.

- KB

2011/2/21 Karanbir Singh [...]
With other words, what I think that is perfect is really perfect,
other people are just time consuming idiots without technical
knowledge. And they don't contribute to the project so they have to
shut up. Did you ever asked yourself why so less people contribute to
the CentOS project? Maybe it has something to do with the CentOS
project and not with the fact that are only idiots out there who can't
contribute to the project.

Kind regards, Thomas

P.S.: I set up a mock/script based infrastructure as a proof of
concept for a fork in less than four weeks from scratch, so it can't
be so much rocket science to get C6 up and running if enough people
sort out the remaining build problems.

1) RHEL is the intellectual property of RedHat, subject to the
licenses of the work of OSS giants
2) RH will seek to maximize RH shareholder equity
...
3) RH has hand-selected certain RH employees to perform the CentOS
project, not more, not fewer
4) to make it more difficult for competitors, there are in Lamar's
words, sniggles
5) RH pays partial lip service to "we stand on the shoulders of OSS giants"
6) RH looks at CentOS as a farm club of future rate-payers

IOW, much of this is about #3.

I think you need to lay off the consperacy theories Larry, really. Just because the devs have better things to do right now (like completing 4.9/5.6/6) rather than training a bunch of newbies, that does not automatically mean that they are trying to protect exclusivity...only productivity. IMPO we would all be a lot better off if everyone here would lay off the core team and let them do their work.

-David

Am 22.02.11 18:22, schrieb Larry Vaden:

Can you please stop your senseless drivel on all kinds of mailing lists
around the CentOS project? This is the first time that I've been asked
by *many* members of the community to remove someone from the mailing
lists, namely you.

And I must say that I do understand them while trying to catch up on
mailing list things at the moment.

Ralph

Ralph, thanks for your input --- it is fully appreciated.

I was about to ask Johnny a question, but now I see I probably
shouldn't unless privacy is irrelevant. If privacy is irrelevant,
then you can hit DELETE now.

Did the count of 8 million

. come from a SWAG
. came from monitoring installs
. came from monitoring unique (e.g., mac-based) installs
. additional choices based on what you know about the count

===genesis:

Well Thomas ... when you have a thousand server infrastructure to serve
6-8 million unique computers with every update then you would rival the
CentOS project.

10-15 people on a mailing list continually whining is one thing ... 8
million machines served is the real thing.

Hello,

But Thomas is not doing things different from Centos; rpmbuild --rebuild
(using mock and koji of course) ...
There is "no magic sauce" as you said, Centos is only rebuilding srpms from
RHEL.
So install rpms on One or Millions of computers is the same, after all
RH does
the hard work (RH and the "million" of programmers that contribute to
software under GPL/LGPL/... license).

ps: long live to puppet / fabric (http://docs.fabfile.org/0.9.4/) ; One,
One thousand, millions ..;)

Regards

js.

2011/2/22 Johnny Hughes [...]
Scaling is something that is part of the architecture of a project,
technical and functional. Having a major slow down in getting things
up an running (4.9, 5.6 and 6) means there is a fundamental lack of a
scalable architecture (and yes, I know about what I'm talking about,
companies I'm working for are providing services for million of
peoples without the help of mirrors). It is completely unbelievable
that the CentOS team still think that is no real problem that releases
take so much time simply because three releases start at the same
time. This is something that could happen every time in the future
again. So it's time to think about the architecture of the project and
how to spread the load to more people to have three completely
independent release teams and release cycles in the range of four
weeks after RHEL GA versions.

And to make my point clear, I don't believe it is rocket science to
get such a release cycle established if _more_ skilled people are
involved in the release creation (beyond translation work).

Kind regards, Thomas

I do believe you dont know what you are talking about, have done no
research or aware of the CentOS process. You seem to be going on and on
about getting more eyes on the ball, which is exactly what we attempted
to do last year, and the option is still open.

- KB

2011/2/23 Karanbir Singh <mail-lists at karan.org>
Funny to know that I don't know what I'm talking about but maybe you can be
more specific. As I already pointed out in another mail, for me it look like
that having more than one release at the same time (4.9, 5.6 and 6) result
in a major slow down of release cycle time. This means for me, the project
isn't able to scale (correct me if I'm wrong). When the project can't scale
it is under normal circumstances a matter of human resources or technical
boundaries. As you told me already in December, it is not a technical
problem. So from my point of view it could _only_ be a matter of human
resources in terms that not enough people working on the release (again,
correct me if I'm wrong). To offer my help I asked already in December,
please provide a list of packages that don't compile so that people that are
willing to help can help getting this packages compiled (i.e. with differnet
mock settings or whatever needed to get this compiled). If the recompile
isn't possible because the SRPM is broken they can submit Bugreports to RH.
But I only saw such a list on the SL website (
https://www.scientificlinux.org/distributions/6x/build/problembyrpm), not on
the CentOS website.

What I heard in the meantime is that CentOS has a policy that the next
release must be compiled with CentOS what I think is a bit funny simply
because RedHat don't use a build environment based in RedHat (I read an
article in the press indicating that they use FC12 koji with some FC13, FC14
backports, but I can't proof this). But the point is still, if you and your
team allow skilled people to support you in the release creation (not by
signing packages or so, but to work out open items, problems, whatsoever) it
is something that the CentOS project will benefit, specially if you look at
the mails currently on the list, most mails are from the same type, when is
CentOS X.X released and why isn't it already released.

Kind regards, Thomas

Why isn't SL released yet ... why did Oracle only release it last week
... because it takes time and it is hard.

If you want to use CentOS, feel free to use it. If you don't, feel free
to leave.

I do appreciate everyone's efforts!

I have a few idle servers locally that can be used for compiling, but
unfortunately cannot make the servers accessible to the outside. If that
helps, I am willing to toss in CPU cycles.

2011/2/24 Johnny Hughes [...]

Why isn't SL released yet ... why did Oracle only release it last week
A lot of the things take time and a lot of things are hard. And in most
cases the process could be simplified and the speed could be increased, but
only if the process, man power, whatsoever is optimized.

Very constructive! I'm not on this list because I use Oracle, SL or any
other rebuild of RHEL, I'm using CentOS and I would like to stay with
CentOS. But if no comment is taken serious I'm not convinced if this is a
smart decision.

Kind regards, Thomas

Oracle released RHEL 5.6 on january 12th. Scientific Linux has a rolling
release since early february.

Given that Red Hat released 5.6 on Jan 13th, its interesting that you
say Oracle had their build out on the 12th. Also interesting and worth
noting is that 5.6 sources stock was still making its way to ftp.r.c a
few days back ( well into second half of Feb ). Its blatantly clear that
neither Oracle nor SciLinux are operating with the same model as are.
And I think its also quite clear that we don't really give a rat's ass
about what Oracle or SciLinux are doing.

So, can we just give up all this random noise now

- KB

I meant to say january 20th, another lapsus on my part:

http://blogs.oracle.com/linux/2011/01/oracle_linux_56_now_available.html

Then Johnny shouldn't have brought it up, should he ? I was simply filling
in the facts.

For those without a LWN subscription, the discussion was mentioned on LWN:

http://lwn.net/SubscriberLink/429364/d1bdc6e1e6e58d0b/

which, incidentally, is where I got that Oracle release date from.

Quality of lwn.net isnt quite what it used to be :/ there are so many
factual mistakes in that piece.

- KB

They (SL) do not recommend rolling in production ... we don't release
things we don't want used in production. There is nothing wrong with
either approach, but it is not fair to compare a final release to a
beta/alpha release.

Dag,

One can read that you are very prolific and that there is a community
of developers who help you with your transparent process.

What is the URL that describes your process?

kind regards/ldv/vaden at texoma.net --- Transaction ID: 2V060708WB590000G (2/8/06)

Hi Larry,

Everything is available from:

http://svn.rpmforge.net/svn/

we have a viewvc front-end and a mailinglist to keep track of changes
here:

http://svn.rpmforge.net/viewvc/
http://lists.rpmforge.net/mailman/listinfo/svn-commits

And there are mailinglists to suggest changes or discuss packages. But at
least everything is shared.

We don't have the community size, nor the infrastructure, nor the
financial baggage that CentOS has, so it may not be a good comparison.

I would like to say that in my opinion the system mentioned above
sounds better than what there is now, for outsiders.

Now, I don't want outsiders to have access to the GPG keys, nor the
ability to push out new versions, but being able to see the source tree
as it is, and being able to download a mock config + setup instructions
would go a long way (again in my opinion).

Forgive my naivete, but what is preventing us from doing such a
thing? Is this a lack of manpower/resources to set it up, or is this
more political as in; we don't want other rhel based distros to steal
our juju?

For those about to say, help out or don't; I have helped out. I did
a handful of patches last month after reverse engineering the process
(http://thread.gmane.org/gmane.linux.centos.devel/6903/). Fast forward a
month, and none of the bug ids where I posted patches on have had so
much as their status changed. Before you jump down my throat on that, I
realize the priority was/is Centos 5.6 etc...

I do believe that if we had a system similar to what Dag is using;
someone in the Centos community would have tried the patches I made,
maybe they didn't work and I needed to fix something or maybe they fix
it and upload a better version. I think progress would have been made
that wouldn't have detracted from the centos-devel's focus.

We release our SRPMS, that is our juju. Every patch is there for the
looking.

I have tried to explain, over and over again. You guys are trying to
make the process different than it is.

For most projects where RPMS are produced, you are getting an upstream
tar ball that may or may not have a spec file ... you are creating spec
file, you are creating lots of patches to change where WWW pages go or
what directory things get installed in, etc.

That is not the case with CentOS ... all of those changes are already in
the "SRPM Source Tree". Our #1 goal (by far) is to be able to use that
SRPM package exactly as it is ... to clone it and make our rendering of
it as identical as possible to the original.

For the vast majority of packages, we make no changes. We rebuild it
and test it. If the binary passes the test, we use it. If the binary
does not pass the test we troubleshoot and figure out why it does not
pass the test ... and we change things OUTSIDE the SRPM to fix the
problem.

For example, here is a problem that I had to solve for 4.9 yesterday.
There is a hidden build requirement that the package
gnome-volume-manager requires perl-XML-Parser to be in the mock build
root for the package to build properly. This is NOT called out in the
SRPM. We need to add it to the tree to build this package ... BUT, we
do not modify the SRPM to make this happen, we instead modify the build
root, and submit a BUG upstream for them to potentially fix this package.

Since our goal is NOT to change upstream packages at all, this would not
show up in this "SVN" or "GIT" tree of all the packages ... since we do
not change (or want to change) the package that upstream has produced.
In any other project besides CentOS, the fix would take 1 minute, it
would be to add a "Build Requires: perl-XML-Parser" to the spec file in
the SVN repo and regenerate the SRPM package.

So, this time consuming tree that you want guys want us to create is not
worth a hill of beans and adds nothing for the vast majority of
packages, since the SRPM is unmodified from upstream.

You have everything you need already in the SRPM.
What makes you think that we HAVE a "split" source tree?

CentOS builds someone else's SRPMS ... that IS our source tree, the
SRPMS that are produced upstream.

We only change a handful of SRPMS (the ones that are labeled .centos).
We are not creating these packages, and in fact it is desirable that
they do not change at all.

We would be creating extra work to break down the SRPMS into their
component parts and create this so called source tree.

What would be the benefit of all this extra work since we do not change
the vast majority of the packages.

Johnny,

Although one can read on this list that you are no longer with the
CentOS Team, we are glad to hear that you are still on the CentOS
Team.

Is what you describe above what Lamar describes on this list as sniggles?

What do you think is the root cause of such things @ the upstream?

kind regards/ldv/vaden at texoma.net

Following Troy's style manual,

p.s. In an effort to rid our site of proprietary backup for Windows
boxen in favor of OSS backup, we ran into more or less the same thing
with rsync (compilation errors in the BSD environs for revs > 2.6.8).
This _may_ explain why RH5 uses rsync-2.6.8.