Description of problem: When trying to add drpms to a repo, I am facing "Skipping: package is xxx > than the max_delta_rpm_size" warnings AFAIU, createrepo refuses to create drpms from rpms with a size > 100000000. [cf. http://createrepo.baseurl.org/ticket/5] In my case, this behavior prevents creation of drpms for exactly those packages which would benefit from drpms most (as using a hacked up createrepo proves: drpm-sizes ~5MB, instead of 120-180MB for the *.rpm). Proposal: Make mas_delta_rpm_size a configurable item or a createrepo option, because all hard-coded limits will fail in some situations. Version-Release number of selected component (if applicable): createrepo-0.9.8-3.fc12.noarch Additional Info: For now have to resort to using a hacked up version of createrepo.
diff --git a/genpkgmetadata.py b/genpkgmetadata.py index 729179f..280d375 100755 --- a/genpkgmetadata.py +++ b/genpkgmetadata.py @@ -112,7 +112,9 @@ def parse_args(args, conf): help="the number of older versions to make deltas against") parser.add_option("--read-pkgs-list", default=None, dest='read_pkgs_list', help="output the paths to the pkgs actually read useful with --update") - + parser.add_option("--max-delta-rpm-size", default=100000000, + dest='max_delta_rpm_size', type='int', + help="max size of an rpm that to run deltarpm against") (opts, argsleft) = parser.parse_args(args) if len(argsleft) > 1 and not opts.split: errorprint(_('Error: Only one directory allowed per run.')) see if that patch does what you want. If so I'll push it upstream and into a release.
Thanks, your patch seems to work. BTW: I am facing python tracebacks when trying to create drpms on FC11. # createrepo --deltas tmp/i386 ... Saving Primary metadata Saving file lists metadata Saving other metadata Saving delta metadata Traceback (most recent call last): File "/usr/share/createrepo/genpkgmetadata.py", line 233, in <module> main(sys.argv[1:]) File "/usr/share/createrepo/genpkgmetadata.py", line 207, in main mdgen.doPkgMetadata() File "/usr/lib/python2.6/site-packages/createrepo/__init__.py", line 368, in doPkgMetadata self.closeMetadataDocs() File "/usr/lib/python2.6/site-packages/createrepo/__init__.py", line 602, in closeMetadataDocs self.deltafile.write(self.generate_delta_xml()) File "/usr/lib/python2.6/site-packages/createrepo/__init__.py", line 691, in generate_delta_xml drpm_rel_fn) File "/usr/lib/python2.6/site-packages/createrepo/deltarpms.py", line 48, in __init__ self._getOldInfo(fo) File "/usr/lib/python2.6/site-packages/createrepo/deltarpms.py", line 71, in _getOldInfo if compobj.read(4)[:3] != "DLT": File "/usr/lib64/python2.6/gzip.py", line 219, in read self._read(readsize) File "/usr/lib64/python2.6/gzip.py", line 255, in _read self._read_gzip_header() File "/usr/lib64/python2.6/gzip.py", line 156, in _read_gzip_header raise IOError, 'Not a gzipped file' IOError: Not a gzipped file Known issue?
if you're on f11 then you might want to check you have the latest rpm and deltarpm installed. I thought some of them went to xz/lzma which might be the problem above. no matter what it is a very different bug.
OK you want it the bureaucratic way - Separate bug filed. Also: Reopening - FIXED UPSTREAM means "BUG is NOT FIXED" in Fedora. Close bugs when it is fixed in Fedora - This is not an upstream tracker, this is Fedora's bugtracker and a complaint against a component in Fedora!
It's not about bureaucracy it's about keeping things in the right pile and organized. please don't reopen the bugs I close as upstream. That helps me keep track of them. I wasn't closing this bug to be confrontational - it's just how I organize my bugs. thanks for opening the new bug.
(In reply to comment #5) > please don't reopen the bugs I close as upstream. What kind of clue stick does it take to make @RHs comprehend that "FIXED UPSTREAM" is a rude and bold lie to cheat the community? Fact is: This issue is still reunsolved in Fedora 12, you are cheating to yourselves and to everybody else about this issue. > I wasn't closing this bug to be confrontational Rest assured, the fact you closed this bug was confrontational and the fact you closed it again, made this even worse.