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