F20 System Wide Change: Perl 5.18

[Paul Howarth]

On 07/08/13 09:56, Marcela Mašláňová wrote:
> On 08/07/2013 03:01 AM, Dennis Gilmore wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> On Tue, 06 Aug 2013 13:39:31 -0700
>> Adam Williamson <awilliam at redhat.com> wrote:
>>
>>> On Thu, 2013-06-13 at 11:10 -0600, Kevin Fenzi wrote:
>>>> On Thu, 13 Jun 2013 13:23:51 +0000 (UTC)
>>>> Petr Pisar <ppisar at redhat.com> wrote:
>>>>
>>>>> On 2013-06-12, Kevin Fenzi <kevin at scrye.com> wrote:
>>>>>> So, there's nothing preventing the side tag and rebuild anytime
>>>>>> now right? 5.18.0 is out, so we could start that work in
>>>>>> rawhide?=20
>>>>>>
>>>>> Currently 5.18.0 does not pass one test when running in mock and
>>>>> koji. (It's because of the terminal usage in tested perl
>>>>> debugger.) We think we could have solved this issue in a few days.
>>>>
>>>> Cool.
>>>>
>>>>> Could you explain how the side tag inheritance works? It inherits
>>>>> everything from rawhide, even builds made after the side tag
>>>>> creation,
>>>>
>>>> yes.
>>>>
>>>>> except packages whose builds have been already made in the side
>>>>> tag. Am I right? That means we still get fresh third-party
>>>>> dependencies from rawhide.
>>>>
>>>> yes. However, there's are several downsides:
>>>>
>>>> - Each side tag adds newrepo tasks which increases load a lot.
>>>> - If you rebuild perl-foo-1.0-1 in the side tag against the new
>>>> perl, then the maintainer has to fix something in rawhide, they
>>>> would build perl-foo-1.0-2 in rawhide and when the side tag was
>>>> merged back over either everyone would get the older one with the
>>>> bug, or the newer one against the old perl. So, it's really
>>>> important to not take a long time using a side tag to avoid this
>>>> problem as much as possible.
>>>
>>> Seems like this one came true in practice. It seems like a 5.18
>>> rebuild run was done in a side tag and then merged back into Rawhide.
>>> Unfortunately, quite a lot of the 5.18 rebuilds seem to have been done
>>> prior to the general F20 mass rebuild - so the mass rebuild won out,
>>> and effectively squelched the perl rebuild.
>>
>> The f20-perl tag was merged back before the mass rebuild was started.
>> so everything in the mass rebuild was built against the new perl.
>> however because the perl rebuild was at a week there was quite a few
>> packages rebuilt against the old perl. we need to work out how to build
>> perl quicker. your analysis is not really correct.
>>
>> Dennis
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v2.0.19 (GNU/Linux)
>>
>> iEYEARECAAYFAlIBnHcACgkQkSxm47BaWfeWKgCeKSTmyV0Yrn9oulqe3UfCgEFH
>> ZxgAn3vU40FXlBwcxg7hRpyx40OeGdVN
>> =fMp/
>> -----END PGP SIGNATURE-----
>>
> If someone knows about a tool, which can give build order faster than
> Petr's tool, then it would help ;-)

How long does Petr's tool take? My script runs in a couple of hours, 
most of which is the time it takes to grok the bootstrap build 
dependencies from git. It also only considers building packages that 
provide perl modules (basically those that would need a MODULE_COMPAT_* 
dependency) rather than everything that merely might have the slightest 
dependency on perl.

Paul.