Re: More explanation requested for warning about rawhide inheriting updates
Eric Smith wrote:
I've seen that done, but didn't know the purpose. I think it's the
right case in my situation. I've updated muParser in rawhide, and am
pushing updates for F16 and F17. muParser has a new so version.
Meshlab depends on muParser, but meshlab currently won't build in F17
and rawhide due to GCC 4.7 becoming more picky about C++ namespace
rules. I'm waiting for help upstream with getting Meshlab to build with
GCC 4.7, but in the mean time I want to do a rebuild of meshlab for F16
to use the new muParser. It looks like I should add the .1 suffix
after %{dist}for F16 and push an update.
No:
* You cannot push the new muParser to F17 because it breaks dependencies if
Meshlab is not rebuilt against it.
* You cannot push the new muParser to F16 if you aren't pushing it to F17
(which isn't possible due to the above) because it breaks the upgrade path.
Thus, you cannot push any muParser updates until you resolve the meshlab
build issue.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
More explanation requested for warning about rawhide inheriting updates
The Join the package collection maintainers page gives the warning: Be sure that you build for rawhide (master) branch before pushing updates for any other branches! Otherwise, those updates will get inherited into rawhide, which is almost certainly not what you want. I've never really understood that, but it's never previously caused me any concern. Since I am now in a situation where I want to push an update to a branch (f16) without pushing any change to rawhide, it has me worried. Can someone please elaborate on how this inheriting updates into rawhide works, and what can be done to avoid it? I suppose the meaning is probably crystal clear to everyone else who has read that warning, but apparently I'm being dense again. Thanks! Eric -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: More explanation requested for warning about rawhide inheriting updates
On Sat, Mar 10, 2012 at 02:14:50 -0800,
Eric Smith e...@brouhaha.com wrote:
The Join the package collection maintainers page gives the warning:
I've never really understood that, but it's never previously caused
me any concern. Since I am now in a situation where I want to push
an update to a branch (f16) without pushing any change to rawhide,
it has me worried. Can someone please elaborate on how this
inheriting updates into rawhide works, and what can be done to
avoid it? I suppose the meaning is probably crystal clear to
everyone else who has read that warning, but apparently I'm being
dense again.
Rawhide inherits from updates of the most recent branch, which is currently
the branched release (f17). Updates will inherit from the release.
A package is only inherited if there are no builds for it at the current
level. So if a package has been built for F18, even if there is a build
with a higher version (actually it would be the latest build, not the
build with the highest version) in F17 release, that build would not
be used for rawhide.
So once you start making a build for a later release, you really want to
continue making builds for that later release.
Stuff in updates-testing doesn't get inherited into rawhide. So if there
are important fixes in updates-testing that may be sitting for a while,
you may want to consider doing builds for rawhide if you aren't already.
(Personally, I'd like to see rawhide changed to inherit from updates-testing.)
If the version used in rawhide is lower than that used in a previous
release (including its updates repo), then trying to use yum update to
go between releases gets more complicated. Currently the situation is
that you pretty much want to use yum distro-sync to update. However this
can end up removing stuff that you'll want to track so that you can
get copies later when things have been fixed. And sometimes things are
complicated enough the yum distro-sync won't be able to work either.
There is a trick to use when you want to make an update for one release
that you won't be doing in later releases and where you want to keep
the later release versions higher than the update. You can add .1 (or
.2 etc) after %{dist}.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: More explanation requested for warning about rawhide inheriting updates
Bruno Wolff III wrote:
Rawhide inherits from updates of the most recent branch, which is
currently the branched release (f17). Updates will inherit from the
release. A package is only inherited if there are no builds for it at
the current level.
[and more good explanation]
Thanks! That's exactly what I needed to know.
There is a trick to use when you want to make an update for one
release that you won't be doing in later releases and where you want
to keep the later release versions higher than the update. You can add
.1 (or .2 etc) after %{dist}.
I've seen that done, but didn't know the purpose. I think it's the
right case in my situation. I've updated muParser in rawhide, and am
pushing updates for F16 and F17. muParser has a new so version.
Meshlab depends on muParser, but meshlab currently won't build in F17
and rawhide due to GCC 4.7 becoming more picky about C++ namespace
rules. I'm waiting for help upstream with getting Meshlab to build with
GCC 4.7, but in the mean time I want to do a rebuild of meshlab for F16
to use the new muParser. It looks like I should add the .1 suffix
after %{dist}for F16 and push an update.
Eric
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
