On Sun, Jan 2, 2011 at 12:48 AM, Lucian <lucian@xxxxxxxxxxx> wrote:
> On Sun, Jan 2, 2011 at 4:00 AM, Nico Kadel-Garcia wrote:
>> You can do it inside the mock chroot cage. I do, on occasion. The
>> difficult is that I find myself wanting things like emacs to edit code
>> and patches, RCS to manage versions of my new .spec files, and
>> unpredictable dependencies as I wrote the code.
>>
>> If necessary, I use one text window (with Alt-F2) to run "mock
>> --shell" and get that working shell window, and another window (with
>> Alt-F3) to drop other RPM's into /var/lib/mock/[whatever]/root/tmp/
>> and be able to install them in the other windows. But I'm a complete
>> weasel.
>>
>> I also use the 'mock' from 'epel-testing', which has some very useful
>> features not in the version of mock from CentOS 5.
>> _______________________________________________
>> CentOS mailing list
>> CentOS@xxxxxxxxxx
>> http://lists.centos.org/mailman/listinfo/centos
>>
>
> Thanks Nico. I ended up building the srpms outside mock as it was just
> too much hassle.
> What are the advantages in using mock from epel-testing?
>
> Regards,
>
> Lucian
Better behavior with extensive autofs tables. (Older mock, in my
experience, gets very confused and starts force unmounting direct
automount targets in the midst of processing, which is *nasty* and
disables my home directory in my fairly odd setup.) Also, the
'lastlog' tables and other sparse files make for *much* too large of
cache.tar.gz files. See this bug
(https://bugzilla.redhat.com/show_bug.cgi?id=633435)
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
