On Fri, 15 Jan 2016 09:24:36 +0100 Tomáš Smetana <tsmetana@xxxxxxxxxx> wrote: > On Wed, 13 Jan 2016 14:38:08 +0100 > Florian Festi <ffesti@xxxxxxxxxx> wrote: > > > On 01/13/2016 02:36 PM, Reindl Harald wrote: > > > > > > > > > Am 13.01.2016 um 14:30 schrieb Richard Hughes: > > >> On 13 January 2016 at 13:13, Reindl Harald > > >> <h.reindl@xxxxxxxxxxxxx> wrote: > > >>> so there is no justification to declare one need to install > > >>> from scratch just because rpm which works for many years fine > > >>> changes it's storage format > > >> > > >> I don't think anyone said there was a need to reinstall from > > >> scratch > > > > > > so how do you translate "clearly not forward compatible"? > > > > "forward compatible" means the old version of a program being able > > to read/process newer version data. > > > > The current rpm versions will not be able to read the new database > > format. > > I tend to use systemd-nspawn containers for building rpms. So for > example, I have a Fedora 24 system and use its dnf to create e.g. > Centos 7 container root and then build Centos rpms from within that > container. If I understand the change correctly, this is going to > break since the Centos 7 rpm-build will not be able to read the > database created by the Fedora 24 dnf. > > I know more people using dnf/rpm to "manage" the containers and this > is somewhat a regression for us. I'm not sure there is a way to > prevent this breakage... So just FYI. :) won't regular mock chroot have the same problem? Dan -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx http://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx
