[rdo-list] [DLRN] Options to pin packages when needed

Alfredo Moralejo Alonso amoralej at redhat.com
Thu Jun 23 11:06:23 UTC 2016


On Thu, Jun 23, 2016 at 12:48 PM, Javier Pena <javier.pena at redhat.com> wrote:
>
>
> ----- Original Message -----
>> 2016-06-23 9:14 GMT+02:00 Javier Pena <javier.pena at redhat.com>:
>> > Hi all,
>> >
>> > RDO Trunk repos are meant to package the latest upstream commits, but in
>> > some rare cases we may need to pin a specific package to a non-latest
>> > commit to temporarily fix a breakage.
>> >
>> > This week, we had one of those cases with keystonemiddleware, but the
>> > procedure used to do it caused some disruption because some commits were
>> > rebuilt, breaking the current-passed-ci and current-tripleo repos for
>> > centos-master.
>> >
>> > Looking for alternatives, my first idea was the following:
>> >
>> > - Temporarily take that package out of rdoinfo using a specific tag (e.g.
>> > tag: to-fix)
>>

I like this idea, just note that this must be a per-release tag,
package pin should for a specific release.

>> if possible, I'd like DLRN to keep building these to keep track of
>> their statuses and allow running CI jobs so that they don't get left
>> out.
>> It'd mean adding logic so that DLRN skip regenerating repo snapshot
>> and put them in a separate staging repo.
>>
>> Considering the low number of pinned packages, I'm +0 about it.
>
> Would it work if we just added the package to the overrides repo, making sure it has a higher version number (or epoch)? The only issue I can think of is upgrades.
>
>>
>> > - And add a working package to an "overrides" repo, included as part of
>> > delorean-deps.repo
>>
>> +1
>>
>> >
>> > This avoids any DLRN db hacks, but stops processing updates for the package
>> > until the breakage is fixed.
>> >

keep building packages would be ideal but i guess we should expect
pinning packages will be exceptional and not to overcomplicate things,
unless reality proves we need it.

>> > What do you think? Any alternative ideas?
>> >
>> > Thanks,
>> > Javier
>> >
>>
>> This is likely the best path.
>>
>> H.
>>
>> _______________________________________________
>> rdo-list mailing list
>> rdo-list at redhat.com
>> https://www.redhat.com/mailman/listinfo/rdo-list
>>
>> To unsubscribe: rdo-list-unsubscribe at redhat.com
>>
>
> _______________________________________________
> rdo-list mailing list
> rdo-list at redhat.com
> https://www.redhat.com/mailman/listinfo/rdo-list
>
> To unsubscribe: rdo-list-unsubscribe at redhat.com




More information about the dev mailing list