Reply on 10-11-2006 13:59:54 <<<> On 2006-11-10 11:34:02 +0100, Dominique Leuenberger wrote:
Reply on 10-11-2006 12:32:07 <<<> On Thu, Nov 09, 2006 at 11:25:29AM +0100, Dr. Peter Poeml wrote: If we move or copy a package from one project to another, what happens to the release number?
I suppose, it starts to count from the beginning. Is that correct?
It starts with the release number contained in the specfile.
Hi,
I guess that is a not-yet-implemented theorie. Up to now, I've never seen BS using my Release-Number inside a spec file, but always replacing it with n.1 / n+m.1 (or by retriggering n.o / n.o+1)
But it would be nice if at least the spec file would be respected (as on a local build, the spec file is fully respected for this)
i am getting tired to explain this. the buildservice _has_ to keep its release number. if it would always honor the release number you could get into the situation where you cant update your package as you have a smaller release number. with the current way we guarantee your newly build packages are always installable.
Darix, In normal case, this is probably true, but in a case I just had, it was BAD: - I have a package in my home-repo, linked to an outside, public repo. - I modify a pkg in my home repo - as linking is not working in the BS, I have to delete the link in games:... - I recreate the link in games:... BS builds the package, starting with %{version}-1.1, even though the old package was 'already' at 1.2. So the only solution I had in this case was retriggering the build process twice to fix this. In my SPEC-File was written Release 2.1. You see, it might be a good choice to interpret the release in case it's a higher number compared to what BS is offering/suggesting. There ARE some pacckagers, that seem to think from time to time when they do something. Regards, Dominique