Bug 69211

repackage support is still pretty beta, so this will definately
change before the final release.

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?

*** Bug 69293 has been marked as a duplicate of this bug. ***

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...)

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?

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.

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.

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...)

> 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...

>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....

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.

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?

repackaged packages are writting to /var/spool/repackage by default now.