Bug 69211 - _repackage_dir is hardcoded to /var/spool/up2date
_repackage_dir is hardcoded to /var/spool/up2date
Status: CLOSED WORKSFORME
Product: Red Hat Public Beta
Classification: Retired
Component: up2date (Show other bugs)
limbo
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Adrian Likins
Jay Turner
:
: 69293 (view as bug list)
Depends On:
Blocks: 67218
  Show dependency treegraph
 
Reported: 2002-07-18 20:35 EDT by Michael Schwendt
Modified: 2015-01-07 18:57 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2002-07-22 22:10:51 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Michael Schwendt 2002-07-18 20:35:14 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020625

Description of problem:
https://listman.redhat.com/pipermail/limbo-list/2002-July/000999.html
https://listman.redhat.com/pipermail/limbo-list/2002-July/001002.html


Version-Release number of selected component (if applicable):
up2date-2.9.13-7.x.9


How reproducible:
Always

Steps to Reproduce:
1. Change up2date's spool dir to something different from /var/spool/up2date.
2. Let up2date fetch several hundred MiB of update packages.
	

Actual Results:  See how it repackages installed rpms in /var/spool/up2date
which fills that partition if it has not enough free space.


Expected Results:  It should repackage rpms in a configurable directory,
preferably one which is different from up2date's spool directory and which is
NOT hardcoded in /usr/lib/rpm/macros.
Comment 1 Adrian Likins 2002-07-18 21:02:10 EDT
repackage support is still pretty beta, so this will definately
change before the final release.
Comment 2 Aleksey Nogin 2002-07-20 22:53:31 EDT
Other issues with repackaging:

(2) Need a way to disable it.

(3) Currently it seems to create illegal packages:

rpm -qip rpm-build-4.1-0.34.i386.rpm
warning: Expected size:       109286 = lead(96)+sigs(344)+pad(0)+data(108846)
warning:   Actual size:       109382
error: rpm-build-4.1-0.34.i386.rpm: No signature available
error: query of rpm-build-4.1-0.34.i386.rpm failed
Exit 1

Note that the repackaged rpm is always 96 bytes bigger than it should be - could
it be writing the lead twice?
Comment 3 Aleksey Nogin 2002-07-21 11:24:24 EDT
*** Bug 69293 has been marked as a duplicate of this bug. ***
Comment 4 Adrian Likins 2002-07-22 17:54:42 EDT
configuration stuff for turning this on/off, the dir, etc
is in the pipe. 

If the packages that get created or incorrect, best bet is
to file a bug against rpm itself with the info (this is
a fairly new rpm feature, so there are undoubtedly issues...)
Comment 5 Adrian Likins 2002-07-22 18:22:28 EDT
random thoughts on what needs to be done to fix this...

the rpm macros for the proper repackage dir needs to be
set, which it currently isnt doing. 

config options needed:

repackageDir

and associated commandline option. 

Need to decide if I really want to put the repackaged
rpms in /var/spool/up2date or someplace else. Probabaly
/var/spool/up2date/repackage might be better as a default.

Anyone have opinions on where repackages files go by default?
Comment 6 Aleksey Nogin 2002-07-22 18:32:07 EDT
Yes, a subdirectory seems like a much better default. Also, IMHO either the file
naming scheme or the directory name should include the hostname (I have my
/var/spool/up2date shared over several machines). Actually, on second though the
filename should definitely include the hostname - this way you immediatelly know
this is a "local" package (as opposed to something supplied by Red Hat) even if
you never new about the repackage feature.

P.S. The rpm repackage size error is now bug 69519.
Comment 7 Michael Schwendt 2002-07-22 18:43:53 EDT
I just filed that repackage error as bug #69521 a minute ago. Btw, your one
cannot be accessed by ordinary bugzilla users. Please change that.
Comment 8 Adrian Likins 2002-07-22 19:51:34 EDT
regards to /var/spool/up2date...

well, sharing /var/spool/up2date is a fairly unsupported config
as none of the code is designed for that to be shared. It should
mostly work, as much by accident as anything. 

Theres a strong possibility however, that instead of keeping 
.hdr's lying around, there is going to be a persisent database
of headers on the system. (setup in such a way rpm can use it
as well...). It's essentially a rpm database so there could
definately be problems with doing that over nfs. Which would
make sharing the storageDir more difficult, since it's not
designed to be shared.

Of course, I guess you are actually requesting that it be 
designed to support sharing the storageDir :-) A possibility,
but currently nowhere on the roadmap...

putting the hostname in the filename would be a rpm level change
(since the filename is basically a join key into the transaction
database that rpm creates). 

It could also make it difficult to share repackage rpms between
machines via some mechanism yet to be pondered (but that support
is a long ways off, at best...)
Comment 9 Aleksey Nogin 2002-07-22 20:38:07 EDT
> Theres a strong possibility however, that instead of keeping 
> .hdr's lying around, there is going to be a persisent database
> of headers on the system. 

That's a very nice idea (especially compared to the current implementation - I
believe that currently an .hdr can be re-downloaded up to 4 times is a single
up2date session!), but wouldn't it then make more sense to have a separate db
dir and package dir?

> putting the hostname in the filename would be a rpm level change

Not really - in RPM it is controlled by the _repackage_name_fmt macro (currently
%%{NAME}-%%{VERSION}-%%{RELEASE}.%%{ARCH}.rpm by default). up2date would just
have to set it to something including a hostname...
Comment 10 Adrian Likins 2002-07-22 22:10:46 EDT
>I
>believe that currently an .hdr can be re-downloaded up to 4 times is a single
>up2date session!), but wouldn't it then make more sense to have a separate db
>dir and package dir?

   The multiple downloading is just a bug, it's not supposed to do that. More
than likely the dirs for the db would be different. Still kind of undecided
on where exactly, /var/spool/up2date/headerdb or something is likely. 
/var/lib/up2date/ is another possibilty. Still kind of deciding on the
best places. Maybe something more generic like /var/lib/rpmheaderdb or
something so that other tools can use and populate it as well.

>
>
>Not really - in RPM it is controlled by the _repackage_name_fmt macro >(currently
>+%%{NAME}-%%{VERSION}-%%{RELEASE}.%%{ARCH}.rpm by default). up2date would just
>+have to set it to something including a hostname...

   Hmmm, true enough. A possibility....
Comment 11 Adrian Likins 2002-08-21 14:02:45 EDT
This can be reset by changing the _repackage_dir rpm macro. Since
this effects everything that uses rpm, that seems the best place
to change this.
Comment 12 Michael Schwendt 2002-08-21 14:23:42 EDT
Hmmm, see "Expected behaviour" in original bug report.

The user who decides to change up2date's spool dir from /var/spool/up2date,
possibly due to lack of disk space there, will be surprised to see that up2date
will fill up that directory nevertheless. Also, during my test-drive of this in
Limbo beta1, a full filesystem was NOT detected.

What does QA says to this?
Comment 13 Adrian Likins 2002-08-21 18:54:27 EDT
repackaged packages are writting to /var/spool/repackage by default now.


Note You need to log in before you can comment on or make changes to this bug.