[CentOS-devel] mock using yum .repo file?

[Jeff Johnson]

On Jul 24, 2011, at 1:31 PM, Ljubomir Ljubojevic wrote:

> Jeff Johnson wrote:
>> On Jul 24, 2011, at 12:59 PM, Ljubomir Ljubojevic wrote:
>> 
>>> Alberto Sentieri wrote:
>>> 
>>>> I am also interested in building packages and I do not know where to 
>>>> start from. Is there a howto with the basics on the subject?
>>>> 
>>> [1]: http://www.rpm.org/max-rpm/
>>> [2]: http://fedoraproject.org/wiki/Projects/Mock
>>> [3]: http://fedoraproject.org/wiki/Extras/MockTricks
>>> 
>> 
>> (aside)
>> Um, you *could* be a little bit more verbose and helpful.
>> 
> 
> Too much postings and not much free time meant more errors and that got 
> me a lot of warnings on centos-users ml, I finally unsubscribed, and I 
> am limiting my help for now to what other people do not respond to, on 
> the rest of comm media.
> 

Understood.

Oddly I'm on a mock learning curve as well today, but
	mock running on Lion and koji+mock running on
	armv5te dreamplugs and rpmv7he panda boards

That and this is basically what I read to learn when I started few years 

Those aren't bad pointers, I merely tried to supply some context.

Meanwhile (while I'm here) here's the answers to your questions:

1) Yes, mock uses yum which will use repo files. You likely need
to configure up /etc/mock/* somehow … checking … yes stanzas
like this are merely yum repositories written differently:
	[fedora]
	name=fedora
	mirrorlist=http://mirrors.fedoraproject.org/mirrorlist?repo=fedora-15&arch=i386
	failovermethod=priority
See if someone hasn't configured up mock for cents somehow: that was the point
of my aside: its often quite mysterious how to find the right URI. I have difficulties
all the time.

2) Cleaning is likely to be mapped onto yum cache cleaning (mock goes to
some lengths to preserve a build system image and not download needlessly).
The mock->yum connection is moderately expensive, but the intent is
	1) (initially) populate the chroot with packages
	2) (normally) update the chroot (and the image) with later packages.
The options win the man page are more to work around issues afaict: try-and-see,
the normal operations SHOULD just work and if not think carefully about
what isn't working for your purposes.

3) priorities don't work too well generally (but do work with specific usage cases).
The typical usage case for priorities is to set up a precedence order if/when
there are multiple choices for a package to install. I would always use
whatever is recommended by add-on repositories, and (if you intent is to become
an add-on repository using preferences) well Dag's repository uses priorities nicely
and flawlessly (from first hand experience) and is worthy of study. But you shouldn't
have to do too much with priorities, you will absolutely know when there is a need
to use, because your updates will be breaking, and your preference (which will determine
the priority field) will be clearer.

hth

73 de Jeff

> ago.
> 
> -- 
> 
> Ljubomir Ljubojevic
> (Love is in the Air)
> PL Computers
> Serbia, Europe
> 
> Google is the Mother, Google is the Father, and traceroute is your
> trusty Spiderman...
> StarOS, Mikrotik and CentOS/RHEL/Linux consultant
> _______________________________________________
> CentOS-devel mailing list
> CentOS-devel at centos.org
> http://lists.centos.org/mailman/listinfo/centos-devel