On Feb 4, 2008, at 3:16 PM, Ralf S. Engelschall wrote:

> On Mon, Feb 04, 2008, Jeff Johnson wrote:
>
>> On Feb 4, 2008, at 1:59 PM, Ralf S. Engelschall wrote:
>>> On Mon, Feb 04, 2008, Jeff Johnson wrote:
>>>
>>>>   Modified files:           (Branch: rpm-5_0)
>>>>     rpm                     CHANGES macros.in
>>>> [...]
>>>>   -%patch(b:p:P:REz:F:d:) \
>>>>   +%patch(b:p:P:REz:F:d:) %{shrink:\
>>>> [...]
>>>
>>> Be careful. This I think is now broken as %{shrink:..} and
>>> other new features were not merged onto rpm-5_0.
>>
>> Thanks for noticing. I'll check-in the macro.c builtin changes  
>> momentarily
>> ...
>>
>>> Ok, shrink might be harmless to merge, but in general I think we  
>>> should
>>> not merge new features back into rpm-5_0...
>>
>> For "no-brainers" like %{realpath:...} and %{getenv:...} and % 
>> {shrink:...}
>> I think we're better off being aggressive in order to have common
>> functionality.
>
> IMHO there is no need to have any common functionality. It is just  
> fine
> if something is missing in 5.0. Because if we merge too many things to
> 5.0, 5.1 will never be used and its release is just delayed.
>
> New features should be not merged back as this both destabilizes  
> already
> stable code _and_ at the same time reduces the community interest in
> the forthcoming release(s).
>
> So, this time it is already too late: merge %{shrink}, of course.  
> But in
> general I strongly recommend to _not_ merge back any "features" at all
> -- independent whether they are based on trivial implementations or  
> not.
> Because there is always something one overlooks and a 5.0.X has to  
> be a
> 100% drop-in replacement for 5.0.(X-k). By merging back changes  
> this is
> not the case...
>

The counter argument is librpm-X.Y changing when Y++. While that is
strictly exactly what is needed, an soname change usually prevents
adoption by most linux distros.

>> All else depends on what is signified by "new" and "feature" or  
>> implied by
>> "bug".
>
> Sure, it's a nasty definition issue...
>
>> The rationale for pushing back "#%patch" should be obvious  
>> however. Stoopid
>> issue ...
>
> Sure, so let's merge it, of course.
>

Someplace there has to be a happy balance point between 5.1 and 5.0.x
releases, ans what time scale the changes occur on ....

73 de Jeff ... off to merge %{shrink...}