On 2016-01-15 09:42, Dan Horák wrote:
On Fri, 15 Jan 2016 09:24:36 +0100
Tomáš Smetana <tsmetana(a)redhat.com> wrote:
> On Wed, 13 Jan 2016 14:38:08 +0100
> Florian Festi <ffesti(a)redhat.com> 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(a)thelounge.net> 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?
Mock uses --nodeps when running rpmbuild, because such incompatibilities
already exist - for example when building EL 6 packages on F23 (i.e. RPM
from EL6 cannot read the rpmdb in buildroot)
Michael