Another great update

[Toshio Kuratomi]

On Sun, Mar 07, 2010 at 11:02:46AM -0500, Orcan Ogetbil wrote:
> On Sun, Mar 7, 2010 at 10:55 AM, Toshio Kuratomi wrote:
> > On Sun, Mar 07, 2010 at 07:34:25AM -0500, Orcan Ogetbil wrote:
> >> On Sun, Mar 7, 2010 at 6:08 AM, Michael Schwendt wrote:
> >> > On Sat, 6 Mar 2010 20:47:40 -0500, Orcan wrote:
> >> >
> >> >> On Sat, Mar 6, 2010 at 8:20 PM, Rahul Sundaram wrote:
> >> >> > On 03/07/2010 06:47 AM, Orcan Ogetbil wrote:
> >> >> >>
> >> >> >> Again I say "updates-testing"! Leaving php-5.3 in testing on F-11 for
> >> >> >> a couple months will warn the users what is coming up and gives them
> >> >> >> plenty of time to adapt.
> >> >> >>
> >> >> >
> >> >> > If you have a large codebase two months is barely enough time to even
> >> >> > big evaluating a move
> >> >> >
> >> >>
> >> >> Then make it 3 months, 4 months... Leave it in testing forever if you
> >> >> get too many complaints. But make it available for those who want it.
> >> >
> >> > You want to force the dist users to consider updates-testing.
> >> > That isn't nice, and you won't be successful with such a strategy.
> >> >
> >>
> >> "it is nice." is what users say, not me. I am talking as someone who
> >> has been using this strategy for a long time now. And I claim to be
> >> successful. On the other hand you are claiming that someone who would
> >> do what I did will not be successful. Well, experience wins.
> >>
> >> So far (in the last 15 monnths or so) I have gotten many good comments
> >> and thanks by using this strategy. I got 0 (zero) complaints about a
> >> particular update that shouldn't go into a stable release. The only
> >> complaints I got were about a few packages that I didn't have time to
> >> update in stable releases. People wanted updates.
> >>
> > Just last night I ran into an issue with this model.  Packages in
> > updates-testing aren't available to the buildroot by default.  So when you
> > need a package in updates testing in order to build you need a buildroot
> > override.  If you have a buildroot override, you no longer have the luxury
> > of leaving an update in updates-testing for as long as you think necessary;
> 
> From what I understand, this is not totally correct. You can ask for
> removal from the buildroot override as soon as you are done building
> your package.

This doesn't work either.  If you do that, then the future package build
potentially won't run if you have updates-testing enabled (because the
library in updates-testing won't run with the program that was compiled
against the stable update.)

> In fact, Releng explicitly asks us to tell them when we
> are done so they can remove the override. (are we talking about the
> same issue here?)
> 
I can't find the wiki page documenting buildroot overrides so I can't
confirm this.  I thought that releng was asking for the overrides to be
removed when the package was pushed to stable but I could be wrong.

> This is one part of my model which works but is not perfect. If this
> can be automated, or a packager interface is written for overrides,
> then we are in business.

If the idea is that every packager that has a dependent package is supposed
to turn the override on or off depending on whether they anticipate their
package going to stable before or after the library they're compiling
against we'll need some tools, not just to make submission easier, but also
to inform packagers (before they build) that they must make a choice about
what libraries they want to compile against in updates-testing.

-Toshio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20100307/c319db32/attachment.bin