On 19.04.2007 11:43, Michael Schwendt wrote:
On Thu, 19 Apr 2007 11:00:15 +0200, Thorsten Leemhuis wrote:
Only packages, which are not rebuilt,
keep their old Release. But builds in devel would get a .fc8 dist tag, so
when rebuilding a package why jump to .1 instead of .fc8?
Because we solve the problem in the *long term* once and for all.
It doesn't solve any real problem, since packages that would benefit from
a verified rebuild (under consideration of build logs and testing) would
now sit in the distribution as old builds with a "hidden" dist tag.
Well, that get into the well known "rebuild every package each devel
cycle or not" debate.
It remains an attempt at hiding the dist tag (or the "fc" in it!) for a
purely cosmetical reason.
Agreed. But that's what some people want: don't have a fc6 disttag in
Fedora 7.
The dist tag does not guarantee that a pkg really works for a distribution.
If packages from Fedora 6 work just fine
in Fedora 7 and haven't changed since Fedora 6, that's fine.
Agreed.
Example:
- after F7 was branched change the disttag in devel to be ".1"
- packages that get build afterwards pick it up
- assume we have a mass-rebuild in F8 (we'll have one sooner or later in
any case, so lets just assume F8 for now)
- F8 gets released and no packages shipped with it have a disttag "fc8"
now; new packages build after release get one, as that easier
- F9 sees no mass rebuild; packages that were not rebuild during the
devel cycle F8 -> F9 can stay as they are; F9 gets release and there are
no packages with a ".fc8" in it, so we avoid the confusion we have now
(that is: ship F7 with packages that have fc6 in ENVR)
Yes, it hides/alters the dist tag for all packages that are (re)built
during the next devel cycle. Those, that are rebuilt frequently, lose the
"fc" in the dist tag and cannot get it back until a post-release update is
built.
Yes. But where is the problem with that?
And those, that are not rebuilt between dist releases, remain a
[potential] problem. I'm not a fan of %dist (because of its side-effects
in deps and changelogs), but playing tricks with dist tags makes it worse.
Well, that why I proposed it here, to get such opinions (even if I
disagree with "makes it worse" in this case).
Better would be a proper roadmap that requests package owners to prepare
their packages for test1 (e.g.) and enforce an automated rebuild (with
Release bump and changelog entry) if they don't meet the deadline.
Well, that again gets into the old "rebuild every package each devel
cycle or not" debate. Maybe it would be helpful if FESCo answers this
question sooner or later to get rid of that topic for the near future...
Side note: I was on the "rebuild everything each devel cycle" side in
the past, but during the mass rebuilds of FE[56] (that I in parts
organized) I hit quite a opposition when proposing that on the list; I
changed my mind due to that and think that the benefits of rebuilding
everything each time is not worth the costs.
CU
thl
--
Fedora-maintainers mailing list
Fedora-maintainers@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-maintainers
--
Fedora-maintainers-readonly mailing list
Fedora-maintainers-readonly@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-maintainers-readonly
