On Tue, Mar 31, 2020 at 8:53 AM Panu Matilainen <pmatilai@xxxxxxxxxx> wrote: > > On 3/31/20 2:46 PM, Panu Matilainen wrote: > > On 3/30/20 7:45 PM, Kevin Fenzi wrote: > >> On Mon, Mar 30, 2020 at 12:41:08PM +0300, Panu Matilainen wrote: > >> ...snip... > >>> > >>> No such things needed at this time. The database change is a separate > >>> change > >>> and does NOT come bundled with RPM 4.16, we'll only even consider > >>> switching > >>> that once 4.16 has had a proper shakedown. > >> > >> ok, great. > >>>> > >>>> In either case, it may be hard to have cycles for this while datacenter > >>>> move is happening. It would help if we had a ballpark at least for when > >>>> it will land / some folks willing to get bootstrapping working in koji. > >>>> > >>>> Or what would you think of the idea of landing it in rawhide, but > >>>> keeping default bdb until after we have the move done and can upgrade > >>>> builders to f32? > >>> > >>> This was the plan all along: the dust of RPM 4.16 landing in rawhide > >>> needs > >>> to settle first before any database changes are considered, excact > >>> schedule > >>> depending on all manner of things. I thought this was clear from the > >>> SQLite > >>> change proposal but guess not. > >> > >> Sorry if it was, perhaps I just missed that. ;( > >> > >>> If it was up to us only, I recon we'd be looking to switch over to > >>> sqlite > >>> somewhere between 2-4 weeks from the time 4.16 lands in rawhide but our > >>> schedule is flexible here. What ballpark dates would we be looking at > >>> with > >>> the datacenter move and builder upgrade? > >> > >> ok, 2-4 weeks from tomorrow would be between the 14th and the 28th? > >> > >> Fedora 32 preferred release date is the 21st. I'm really not sure we > >> will have cycles to update all the builders in less than a week. > >> Whats the impact of using rawhide rpm on f31 builders? Will there be > >> deps/issues ? > > > > The soname doesn't change and no dependencies on any rawhide > > latest-and-greatest otherwise, so from that side there shouldn't be any > > issues. > > > > The only real incompatibility should be on the spec parse side - the > > bare word vs quoted strings thing in specs (as explained in my heads-up > > message), which affects a handful of packages but is also trivial for > > packagers to fix if they encounter it. > > > >> We probibly won't move to f32 on the builders until we are installing > >> new ones in the new datacenter and switching to those. But I very leary > >> of also replacing rpm on them at the same time... I guess it could work > >> and we could always back it out if not. That would be the last week of > >> may or so that we switch to those. > >> > >> So, I guess the two windows are: as soon as it looks ok with f31 > >> builders or last week or may/first week of june with f32. Or late june > >> when we are done moving things. > > > > I could live with switching at beginning of May, but end of May / > > sometime in June is terribly late in the cycle for this. So if choosing > > between these, it'd kinda have to be with f31 builders. > > OTOH there are various other possibilities too, including but probably > > not limited to: > > > > a) Switch in two stages: override the database to bdb on builders, > > change rawhide on our own schedule and then remove builder override when > > it suits infra > > b) See if the copr bootstrap is usable now in koji > > c) Just leave the builders alone and see what happens. In theory it > > should all just work regardless as long as all installations are done > > from outside of the chroot. > > After getting some fresh air, aka consulting the dog: it's of course > more complicated than that. > > From the point of getting *packages* built for rawhide, it shouldn't > make the slightest difference what rpm the builders are using at this > time because even if the build runs rpm queries, the rpm on the inside > does still support BDB. From package building perspective the only gain > of having 4.16 on the builders is additional testing - which is nice, > but also could perhaps wait a bit longer. > > However, *image* builds that need the newer rpm to avoid having BDB > database on eg Live images are a different story I suppose. I simply do > not know all the things that are being built, and never mind the details > of how and the interactions. > They boil down to three major processes: * Anaconda based * LiveCD Tools based * CoreOS based All three tools use host RPM to build the target image environment. However, all three are executed in chroots of the target environment. Anaconda and LiveCD Tools based stuff is done so by Koji, and the CoreOS process is done by CoreOS Assembler, which uses OpenShift machinery to build the images. So the tricky problem is that if we tell Koji to export a macro to change rpmdb to bdb, that influences down the chain (except CoreOS, which is not affected by this and will be fine no matter what happens). However, if we _don't_ do anything, we *might* actually be fine, as long as the builders support bdb and sqlite. That means that the only targets where we need the %_db_backend macro set back to bdb are the EPEL targets, and I'm not even sure we need to do it there either. -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
