PMS should document that updates are applied in chronological order of the files, and within each file, in the order that they occur in the file. For example, it plays a role in the case that a slotmove is later followed by a move for the same package. Also: "Any name that has appeared as the origin of a move must not be reused in the future." What does this mean? Is that name burned forever, even if it's later removed from updates?
I believe current policy is that you're not allowed to remove things from updates, and that you're not allowed to move things that have already been moved, hence the wording. Did that change?
(In reply to comment #1) > I believe current policy is that you're not allowed to remove things from > updates, and that you're not allowed to move things that have already been > moved, hence the wording. Did that change? Where is this policy documented? So if a dev makes a mistake and writes "move bar foo" instead of "move foo bar" into the updates file, then by PMS's wording he can never again use "bar" as a package name, because it "has appeared as the origin of a move"?
So far as I'm aware, it's documented in the same place that most of Gentoo's other QA policies are documented, which is to say in single emails sent five years ago... That's part of what makes this such a nuisance. The only removals from updates I can recall are when Seemant removed some of the older updates files several years after they were done, after very carefully checking that it was probably OK to do so. So far as I know no-one ever got around to documenting exactly what had to be done for that. Other than that... There've been a couple of typos removed from there, which caused horrible problems for users... "Developers screwing up" isn't something tolerated by Portage in updates. So yes, this pretty much has to be an absolute, at least the way things are now.
Are your replies related to the last paragraph only, or to the full report?
As far as I can see all the "must not be reused" clause means all the issues in the report are equivalent, so my reply's about the entire thing. Obviously, there's an exception if things get fixed before they hit rsync, and realistically we probably have to have an unwritten exception for things that get caught and fixed quickly, but so far as I know, anything that makes it out to lots of users has to be considered permanent and eternal.
What's the intent here? Are you trying to make it defined behaviour to rename a package to a name that has already been renamed to something else?
See above: "slotmove <cat/foo-2 0 1" exists, but now upstream renamed from "foo" to "bar", so we need to "move cat/foo cat/bar" now. Zac tells me that this just works, without changing the prior slotmove.
The implications of this for overlays are fairly icky, if they don't apply the changes at exactly the same time. Do we care?
(In reply to comment #8) > The implications of this for overlays are fairly icky, if they don't apply the > changes at exactly the same time. The later change (the "move" in my example) must not be applied before the earlier one (the "slotmove") has been applied everywhere? > Do we care? Good question.
(In reply to comment #9) > (In reply to comment #8) > The later change (the "move" in my example) must not be applied before the > earlier one (the "slotmove") has been applied everywhere? Yeah. Is there any way things can break if slotmoves are just re-applied later on for any moves?
(In reply to comment #10) > Is there any way things can break if slotmoves are just re-applied later on > for any moves? Like this? slotmove <cat/foo-2 0 1 move cat/foo cat/bar slotmove <cat/bar-2 0 1 According to Zac, Portage applies it in order, so only the first two lines are necessary.
So in we have: slotmove <cat/foo-2 0 1 move cat/foo cat/bar and a user installs cat/bar-1:0, Portage does the slotmove on cat/bar even though the cat/bar in question has never been called cat/foo?
(In reply to comment #12) > slotmove <cat/foo-2 0 1 > move cat/foo cat/bar > > and a user installs cat/bar-1:0, Portage does the slotmove on cat/bar even > though the cat/bar in question has never been called cat/foo? AFAIK, no. There is no slotmove for cat/bar. (Are we talking about the same thing here?) Portage does the updates in the order that they occur in the file, therefore it cannot happen that an installed cat/foo-1:0 is first moved to cat/bar-1.0 and then misses the slotmove.
Looking at this again, I think the spec is fine as it is. We could add a clarifying note like "In is unspecified in what order package moves are applied.", but I don't think this is strictly necessary. (If we don't specify it, then it is unspecified. :-) As a consequence, the example in comment #11 would need all 3 lines, with no shortcuts allowed. Maybe it is better to require these moves to be explicit.
I've proposed to add the following clarification: https://archives.gentoo.org/gentoo-pms/message/4fde4acef1dd0c85e82f23dfb5ae0322 "It is unspecified in what order the files in the \t{updates} directory are processed. Lines within each file are processed in ascending order."
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/proj/pms.git/commit/?id=897ea77dc60e125899b440496d75011e8ae18742 commit 897ea77dc60e125899b440496d75011e8ae18742 Author: Ulrich Müller <ulm@gentoo.org> AuthorDate: 2021-05-18 22:45:12 +0000 Commit: Ulrich Müller <ulm@gentoo.org> CommitDate: 2021-05-23 09:54:20 +0000 Clarify that updates files are processed in no particular order Bug: https://bugs.gentoo.org/296713#c14 Signed-off-by: Ulrich Müller <ulm@gentoo.org> tree-layout.tex | 3 +++ 1 file changed, 3 insertions(+)
