FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Development

 
 
LinkBack Thread Tools
 
Old 11-21-2010, 04:41 PM
Andre Robatino
 
Default preventing md5 mismatch errors from compression changes

The recent change in xz compression settings caused md5 mismatch errors in
rebuilding RPMs (since applydeltarpm doesn't know the difference between the old
and new compression). This resulted in significant work for releng. To avoid
this issue in the future, what about using different names and packages for the
different compression types (i.e., xz1, xz2, etc.) so they can be installed
simultaneously and identified properly? The xz packages are small, and using
separate packages should hopefully mean little to no extra work for the
maintainer. The same method could be used in the future for any new compression
type that replaces xz.

http://lists.fedoraproject.org/pipermail/devel/2010-October/144651.html

https://bugzilla.redhat.com/show_bug.cgi?id=644046

https://fedorahosted.org/rel-eng/ticket/4224

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 11-21-2010, 06:10 PM
Toshio Kuratomi
 
Default preventing md5 mismatch errors from compression changes

On Sun, Nov 21, 2010 at 05:41:35PM +0000, Andre Robatino wrote:
> The recent change in xz compression settings caused md5 mismatch errors in
> rebuilding RPMs (since applydeltarpm doesn't know the difference between the old
> and new compression). This resulted in significant work for releng. To avoid
> this issue in the future, what about using different names and packages for the
> different compression types (i.e., xz1, xz2, etc.) so they can be installed
> simultaneously and identified properly? The xz packages are small, and using
> separate packages should hopefully mean little to no extra work for the
> maintainer. The same method could be used in the future for any new compression
> type that replaces xz.
>
> http://lists.fedoraproject.org/pipermail/devel/2010-October/144651.html
>
> https://bugzilla.redhat.com/show_bug.cgi?id=644046
>
> https://fedorahosted.org/rel-eng/ticket/4224
>
This could require different naames for the library too which will get a bit
harder than just the binary name.

-Toshio
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 11-28-2010, 07:25 AM
Andre Robatino
 
Default preventing md5 mismatch errors from compression changes

Toshio Kuratomi <a.badger <at> gmail.com> writes:

> This could require different naames for the library too which will get a bit
> harder than just the binary name.

Sorry for the late reply. I just noticed the presence in Rawhide of the
xz-compat-libs package which provides the old compression with liblzma.so.0 in
addition to xz-libs providing the new compression with liblzma.so.5. (This was
also discussed in
http://lists.fedoraproject.org/pipermail/devel/2010-October/144651.html .) This
is great - however, applydeltarpm in Rawhide still fails with "md5 mismatch of
result" when the new RPM uses the old compression. Excuse my ignorance, but is
there some way to make it recognize the correct compression needed? I was hoping
to be able to generate functional deltaisos from F14 Final to various F15
milestones, but at this point it looks like it won't work (even when running
applydeltaiso on a system with the latest xz/deltarpm/deltaiso). If it could be
made to work, I could just document the procedure for temporarily updating the
necessary packages.


--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 11-28-2010, 08:25 PM
Toshio Kuratomi
 
Default preventing md5 mismatch errors from compression changes

On Sun, Nov 28, 2010 at 08:25:49AM +0000, Andre Robatino wrote:
> Toshio Kuratomi <a.badger <at> gmail.com> writes:
>
> > This could require different naames for the library too which will get a bit
> > harder than just the binary name.
>
> Sorry for the late reply. I just noticed the presence in Rawhide of the
> xz-compat-libs package which provides the old compression with liblzma.so.0 in
> addition to xz-libs providing the new compression with liblzma.so.5. (This was
> also discussed in
> http://lists.fedoraproject.org/pipermail/devel/2010-October/144651.html .) This
> is great - however, applydeltarpm in Rawhide still fails with "md5 mismatch of
> result" when the new RPM uses the old compression. Excuse my ignorance, but is
> there some way to make it recognize the correct compression needed? I was hoping
> to be able to generate functional deltaisos from F14 Final to various F15
> milestones, but at this point it looks like it won't work (even when running
> applydeltaiso on a system with the latest xz/deltarpm/deltaiso). If it could be
> made to work, I could just document the procedure for temporarily updating the
> necessary packages.
>
I don't believe so. I think we'd need to 1) rebuild all packages using the
new compression 2) Teach the deltaiso stuff that generating an F15 iso needs
to use the new version of the xz/delta*.

Without a rebuild, some packages in F15 will be using the old xz compression
and therefore fail if the new xz compression is used while other packages
will be using the new compression and fail if the old compression is used.

-Toshio
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 11-28-2010, 11:07 PM
Andre Robatino
 
Default preventing md5 mismatch errors from compression changes

Toshio Kuratomi <a.badger <at> gmail.com> writes:

> I don't believe so. I think we'd need to 1) rebuild all packages using the
> new compression 2) Teach the deltaiso stuff that generating an F15 iso needs
> to use the new version of the xz/delta*.

2) is easy enough. To get F14 to use the new compression unconditionally, I
downloaded the Rawhide version of several packages and then used yum shell with
the commands

config gpgcheck 0
install xz-compat-libs-5.0.0-4.fc15.x86_64.rpm
update xz-5.0.0-4.fc15.x86_64.rpm xz-libs-5.0.0-4.fc15.x86_64.rpm
deltarpm-3.6-0.4.20100708git.fc15.x86_64.rpm
deltaiso-3.6-0.4.20100708git.fc15.x86_64.rpm
python-deltarpm-3.6-0.4.20100708git.fc15.x86_64.rpm
run

and to reverse the process (necessary so yum-presto will work), yum shell again
with the commands

remove xz-compat-libs
downgrade xz xz-libs deltarpm deltaiso python-deltarpm
run

The old and new versions of deltarpm use the old and new compression
unconditionally, resp.







--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 11-29-2010, 11:15 PM
Andre Robatino
 
Default preventing md5 mismatch errors from compression changes

Andre Robatino <robatino <at> fedoraproject.org> writes:

> 2) is easy enough. To get F14 to use the new compression unconditionally, I
> downloaded the Rawhide version of several packages and then used yum shell with
> the commands
>
> config gpgcheck 0
> install xz-compat-libs-5.0.0-4.fc15.x86_64.rpm
> update xz-5.0.0-4.fc15.x86_64.rpm xz-libs-5.0.0-4.fc15.x86_64.rpm
> deltarpm-3.6-0.4.20100708git.fc15.x86_64.rpm
> deltaiso-3.6-0.4.20100708git.fc15.x86_64.rpm
> python-deltarpm-3.6-0.4.20100708git.fc15.x86_64.rpm
> run
>
> and to reverse the process (necessary so yum-presto will work), yum shell again
> with the commands
>
> remove xz-compat-libs
> downgrade xz xz-libs deltarpm deltaiso python-deltarpm
> run
>
> The old and new versions of deltarpm use the old and new compression
> unconditionally, resp.

I'm wondering why the new xz isn't pushed to F14 and below. With xz-compat-libs
providing liblzma.so.0, yum-presto works normally. It's only if
deltarpm/deltaiso are updated to the F15/Rawhide versions that it breaks. Would
anything else break - other than the fact that command-line xz would compress
differently?



--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 11-30-2010, 03:54 AM
Toshio Kuratomi
 
Default preventing md5 mismatch errors from compression changes

On Tue, Nov 30, 2010 at 12:15:25AM +0000, Andre Robatino wrote:
> Andre Robatino <robatino <at> fedoraproject.org> writes:
>
> > 2) is easy enough. To get F14 to use the new compression unconditionally, I
> > downloaded the Rawhide version of several packages and then used yum shell with
> > the commands
> >
> > config gpgcheck 0
> > install xz-compat-libs-5.0.0-4.fc15.x86_64.rpm
> > update xz-5.0.0-4.fc15.x86_64.rpm xz-libs-5.0.0-4.fc15.x86_64.rpm
> > deltarpm-3.6-0.4.20100708git.fc15.x86_64.rpm
> > deltaiso-3.6-0.4.20100708git.fc15.x86_64.rpm
> > python-deltarpm-3.6-0.4.20100708git.fc15.x86_64.rpm
> > run
> >
> > and to reverse the process (necessary so yum-presto will work), yum shell again
> > with the commands
> >
> > remove xz-compat-libs
> > downgrade xz xz-libs deltarpm deltaiso python-deltarpm
> > run
> >
> > The old and new versions of deltarpm use the old and new compression
> > unconditionally, resp.
>
> I'm wondering why the new xz isn't pushed to F14 and below. With xz-compat-libs
> providing liblzma.so.0, yum-presto works normally. It's only if
> deltarpm/deltaiso are updated to the F15/Rawhide versions that it breaks. Would
> anything else break - other than the fact that command-line xz would compress
> differently?
>
Commandline xz would compress differently and other random apps that we
don't know of would as well. This may not cause any difficulties... OTOH,
it could be that people *are* depending on the compression being the same.
breaking that assumption is something we can do at the Fedora release
boundary... not so easily within a Fedora release.

Beyond this, there's the fact that there's not a compelling reason to update
on F14 and that the present plan for the compat libs package is that it will
go away before rawhide becomes F15.

-Toshio
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 11-30-2010, 05:22 PM
Andre Robatino
 
Default preventing md5 mismatch errors from compression changes

Toshio Kuratomi <a.badger <at> gmail.com> writes:

> Commandline xz would compress differently and other random apps that we
> don't know of would as well. This may not cause any difficulties... OTOH,
> it could be that people *are* depending on the compression being the same.
> breaking that assumption is something we can do at the Fedora release
> boundary... not so easily within a Fedora release.

Fair enough, it's possible (though a little tricky) for people who need the new
compression in F14 and below to use the yum shell procedure to temporarily get
it, then reverse the procedure afterwards. I'll just have to make sure to
document it properly.

> Beyond this, there's the fact that there's not a compelling reason to update
> on F14 and that the present plan for the compat libs package is that it will
> go away before rawhide becomes F15.

What about Fedora testers using deltaisos? (For example see
https://fedorahosted.org/rel-eng/ticket/3575 .) During F15 testing, the deltas
after F15 Alpha TC1 should be functional, but will require anyone using them who
doesn't currently have F15/Rawhide installed to use the yum shell procedure I
outlined, to temporarily get the new compression to apply them. Without the
xz-compat-libs package this won't be possible. Many testers such as myself won't
install F15 on bare metal until Final, and even if they were willing, depending
on the state of Alpha TC1 it may not be installable from that. In addition,
people on F15 and above such as myself who temporarily need the old compression
(for a typical use case see
https://fedorahosted.org/fedora-infrastructure/ticket/2241 ) won't be able to do
this at all. Of course, in both directions there's the option of creating a
virtual guest, but this is FAR more painful (both in speed and bloat) then just
having a tiny xz-compat-libs package, together with temporarily up/downgrading
the deltarpm/deltaiso packages - which doesn't require yum shell.

For these reasons alone, I believe xz-compat-libs should be made available
indefinitely in F15 and above, and provide a copy of liblzma.so.* for each older
version of the compression. Since the package already exists, maintaining it
should be trivial. Obviously it doesn't need to be installed by default, just
available in the repo.




--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 

Thread Tools




All times are GMT. The time now is 04:25 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org