RPM tools

seth vidal skvidal at phy.duke.edu
Mon Dec 20 07:49:50 UTC 2004


On Mon, 2004-12-20 at 14:40 +0800, Jeff Pitman wrote:
> On Monday 20 December 2004 13:57, seth vidal wrote:
> > a lot of it has to do with the cvs system in place and internal
> > processes.
> 
> Ok, that's fine. I would just like to reiterate a few things that I 
> think I wouldn't be alone in voicing:

Guess what? you're not alone. Guess what else? I've been doing that for
a long ass time. Things needed to get prepped inside b/c the cvs
infrastructure that Gafton set up has completely changed how internal
structures work. They wanted ONE cvs structure for everything. They had
THREE prior to this so you can see the advantages to getting them all
together. So that everyone is on the same page.

Do you know how long it takes to get everyone inside a medium-sized
company on the same page w/o bringing all productivity to a halt?

I bet it takes something like 6-8 months.

Notice the timeline since cvs was first put in place for fedora? looks
something like 6 to 8 months ago. :)


> 1. These processes are opened up by Redhat.

The memos and emails and bullshit internally really doesn't matter. That
was to get their own people on the same page. It just took some time and
well, that sucks but that's how it was.

> 2. That a formal project be started to refine the build system. (Put it 
> in the "Projects" menu on the fedora.redhat.com website)

That will happen. And, as I know we said earlier, the latest estimate
was sometime shortly after xmas. It depends on availability of time. 
Now, I, personally, think we should be in the 'release early, release
horribly broken'  mode but I know it's not always that easy.
 That's why Me, Colin, Michael and a bunch of others decided to do the
pre-extras release. To build the stuff we had. To show people that:
 1. work was going on
 2. there's stuff in place and wheels are turning
 3. how cool some of it is.

> This will enable all to see that, Yes, we need to mold existing 
> methodologies to what Fedora needs and wow, we can use foo, bar, and 
> baz from these other projects to help facilitate the betterment of this 
> system. Otherwise, we'll be stuck with the "internal process" euphemism 
> for along time while wondering how we can better contribute besides 
> tweaking Buildrequires or perl one-liners in already-existing spec 
> files.

So here's a fun fact: Other projects were looked at and other projects
are being used. But opening up the floor for wide-open debate on the
subject isn't going to get the work done. It's just going to make for a
lot of debate w/little actual forward motion.

What I know of how some of the build system is being worked on for
extras is this:
 - when you check in a package to cvs you can tag it with a special
'buildme' tag. (not the real tag name, obviously)
 - the buildsystem scans for those tags, creates a buildroot using
something like: 
  yum -y --installroot=/someplace groupinstall base development

  it might not be using yum - it might be using rpm directly. I don't 
  know for certain - but as the author of yum I tend to think in yum 
  commands :)

 - the package is built, the logs are dumped to useful places
 

the problems:
  - in order to make building safe you either need to vet all the
potential scriptlets and build commands (hah) or run it in some sort of
virtualized or protected environment. I know gafton said he got
sidetracked trying to get Xen to work in this capacity. But he needed to
go ahead and work on tying all the bits together.
  - you've got to get all the build deps in place and make everything
flow smoothly from checked in package to complete rpm.


That's what going on. That's where we are. It's not a NIH issue. It's a
huge amount of glue coding that's occurring. I agree with you that I'd
like it to be a little more exposed and it's going in that direction.
But seeing as I'm not internal to red hat and I've got a bunch of this
information I hope you can accept my statement that things are opening
up. More and more.

Like I said last week or so, I'll let you know more as I know it.

And I will. Watch the fedora people page
(http://fedoraproject.org/people) I'll try to post entries into my blog
when I get useful info. Okay?

Oh and if you're curious why this doesn't get posted to the fedora-
devel-list by the project leaders themselves my answers are these two:

 1. some of them are not all that talkative and don't always have the
time considering that they're also project managers and developers
inside red hat.

 2. did you see the thread-that-would-never-die from this weekend? :-)

Right now my messages are probably the best you're gonna get.

I'll be glad to field other questions and answer whatever I know.

cool?

-sv





More information about the fedora-devel-list mailing list