[Revisor-users] Customizing Comps

Jeroen van Meeuwen kanarip at kanarip.com
Fri Nov 2 10:33:43 UTC 2007


Bernd Hentig wrote:
> Hello Jonathan,
>>  or add an
>>   
>>> update for the anaconda rpms.
>>> The FC7 repo + the offical update repo combined should always make a
>>> working distro
>>>     
>> There will never (as policy stands now) be an "official" anaconda update
>> during the lifespan of a Fedora release.
>>
>> - hopefully this view is shared by the Fedora developers?
>>
>> We welcome you to demand this from the Fedora Project, we would also
>> enjoy this to be the case but have found it not to be in the past. With
>> a 6 month release cycle it might not be the best use of resources to
>> rebuild anaconda whenever it's broken (or needs an update).
>>
>>   
> I understand the problem since I have done some anaconda for our own
> purposes customization in the past.
> However, the integrity of a Linux distribution is something that decides
> about how many users will be able to install and like it (because it has
> no flaws) and how many adoptors can find a way to create their own
> flavours and thus spread the word (or the ISOs, in our case =)
> This is the main goal of the revisor project, creating more flavours,
> enable easy customization and so spread the Fedora project as much as
> possible - unless I am very mistaken.

You're right ;-)

>>> Or just move the problematic updates to a new repo "testing" or
>>> "unstable" ;-)
>>>     
>> They arn't really "problematic" as the issue is with anaconda.
>>
>>   
> If any updates won't work together with another package in the main
> distro (like anaconda-runtime), I think they should not go into a stable
> updates tree.

You're right; they shouldn't. If the policy is to not update anaconda, 
packages on which it depends should not be allowed to break it.

However, there is no process that makes a Release Engineer rebuilt the 
installer with the updated packages and test it, only to respond back to 
the maintainer of the updated package that broke it to not push the update.

My idea of working around this is to maintain anaconda for a release 
cycle, only fixing bugs that may occur within that release cycle's 
release and updates tree.

Having the updates to anaconda that we see now when the following 
release is released is not going to happen as the installer will most 
likely get new features that are instable for a number of months while 
everyone is testing things.

Kind regards,

Jeroen van Meeuwen
-kanarip


More information about the Revisor-users mailing list