/var/spool/repackage

[Dana Holland]

Thanks.  In our case, it was apparently configured by mistake.  For this 
particular server, if there were a major failure we would be better off 
starting from scratch anyway.

redhat at buglecreek.com wrote:
> On Thu, 08 Feb 2007 16:29:44 -0600, "Dana Holland"
> <dana.holland at navarrocollege.edu> said:
>> Can the files in this directory be removed?  Are /var file system has 
>> filled up.  I was able to find something about removing the files in 
>> /var/spool/up2date but not the repackage directory.
>>
>> -- 
>> redhat-list mailing list
>> unsubscribe mailto:redhat-list-request at redhat.com?subject=unsubscribe
>> https://www.redhat.com/mailman/listinfo/redhat-list
> 
> There are a few things you may want to consider before you remove any
> packages in the directory.  The first one is why are they there.  We
> have enabled this feature on many of our critical systems in the event a
> up2date goes bad.  It has saved us many times.  Not sure what OS version
> you are running, but on our Redhat systems you can try "up2date
> --config" from the command line.  Look for a line that says
> enableRollbacks.  Someone may have enabled this feature.  If you delete
> the files in the directory or disable this feature you will lose your
> ability to perform RPM Transactional Rollbacks.  If you are not familiar
> with this, it enables you to rollback and upgrade quickly if you need
> to.  You can also try to change the location of the repackaged rpms in
> /etc/rpm/macros file if it exists.  If not you can create it.  I believe
> you would need %_repackage_dir dir_location, but I am not able to verify
> this at the moment.  Hope this helps.
>