F20 System Wide Change: Perl 5.18

Marcela Mašláňová mmaslano at redhat.com
Wed Aug 7 08:56:33 UTC 2013


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 ;-)

Marcela


More information about the devel mailing list