Update Management

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, 10 Jul 2002, Thomas Dodd wrote:

>>>found a new XFree86-4.1.0-25.i386.rpm (18.241M, June 14 02).
>>>A few weeks ago, I had pulled XFree86-4.1.0-25.i386.rpm 
>>>(19.681M, April 26 02).  Obviously, these 2 rpms are 
>>>    
>>>
>>Yes, generally that is the way things are handled.  In this case, 
>>some fonts had to be removed from the packages immediately, and 
>>the normal way of doing things was not fast enough to meet the 
>>requirements.  As such the fonts were removed and the packages 
>>respun without changing the release number.
>
>I wonder which fonts?

ulT1mo Type1 fonts

>>I personally would have bumped the release number in a way that 
>>was compatible, however the reason that was not done if I 
>>understand correctly is that we also had to respin the ISO images 
>>with these changes, and bumping the release numbers would have 
>>meant completely regenerating the rpmdb, hdlist, and creating a 
>
>That's a long standing BUG in the installer.  It should be possible to
>Add/change packages to updated versions more easily.

It's not a bug.  The package list is stored in a database for 
speed so that every single RPM package does not need to be opened 
in order to present them to the user for selection at install 
time.  This database is "hdlist" and is generated by genhdlist.

If the package list is changed, genhdlist must be re-ran, and 
also splitdistro.  I fail to see where there is a bug here.


>Droping/replacing the packages in RedHat/RPMS and
>a changing file somewhere in RedHat/base should be enough.

Implement such a solution, and submit it to us.  Make sure it 
solves all of the problems that the current solution does 
(genhdlist), and if it is considered to be superior, then I don't 
see why we would not use it in the future.

In general, people see "solutions" to problems from the angle of 
how the problem affects them however, and to the exclusion of all 
of the problems that existing code is solving.  That doesn't mean 
it can't be done however.  It's just going to take an 
enterprising open source developer with enough time and energy to 
whip it up.



-- 
Mike A. Harris                  Shipping/mailing address:
OS Systems Engineer             190 Pittsburgh Ave., Sault Ste. Marie,
XFree86 maintainer              Ontario, Canada, P6C 5B3
Red Hat Inc.
http://www.redhat.com           ftp://people.redhat.com/mharris





[Red Hat General]     [Red Hat Watch]     [Red Hat Development]     [Kernel Development]     [Yosemite Camping]

  Powered by Linux