Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

package-moves: Allow moving back, and describe how to chain updates #326

Closed
wants to merge 1 commit into from
Closed

package-moves: Allow moving back, and describe how to chain updates #326

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
49 changes: 47 additions & 2 deletions ebuild-maintenance/package-moves/text.xml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -19,8 +19,10 @@ the following must be noted:
</li>
<li>
Once an update entry is created, the old package name (or slot) cannot be
reused. Attempting to reuse it will cause updates to apply again,
to the reused name. This also means that updates cannot be undone.
reused for another package. Attempting to reuse it will cause updates to
apply again, to the reused name. This also means that while a package can
be moved back to its previous name, all the names historically used for
a package are reserved to it alone.
</li>
<li>
Updates can only perform one-to-one moves. They cannot be used to merge
Expand Down Expand Up @@ -113,6 +115,49 @@ you have updated every file in <c>profiles/</c> directory that
happens to contain an entry which may be affected by your change.
</p>

</body>
</section>

<section>
<title>Updating prior update entries when moving the package again</title>
<body>

<p>
When the same package is moved again, the previous update entries should
be updated appropriately. This is meant to make the situation more transparent
to users reading update entries and to ensure that the process is handled
efficiently even if the package manager does not implement updates in a robust
way. This involves the following steps:
</p>

<ol>
<li>
The previous package moves for the package in question must be updated
to reference the final name. That is, rather than the chain A → B → C,
we want to have two update entries: A → C, and B → C.
</li>

<li>
If the package is being moved to a name that it used before, the original
move entry must be removed. That is, rather than the chain A → B → A,
we want to have the reverse entry: B → A. If the package manager did not
move A → B before, we don't want it to touch the package at all.
</li>

<li>
As a combination of the two aforementioned steps, a chain of A → B → C → A
would be replaced by two moves: B → A, and C → A.
</li>

<li>
If the package was slot-moved before, the slot moves should be updated
to use the final package name, and moved after the final package move.
That is, rather than the chain: A:S₁ → A:S₂, A → B; we prefer to have
the chain: A → B, B:S₁ → B:S₂. All package and slot move entries must reside
Comment on lines +155 to +156
Copy link
Member

@ulm ulm Jan 27, 2024 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think that Unicode superscript and subscript characters should be avoided. They are a workaround for plain text but have no place in a markup language like XML or HTML. (In other words, a 1 is a 1 regardless of its appearance in regular text or in a subscript.)

Edit: I suggest to change it to either A:X → A:Y or A:S1 → A:S2. Unless we would expect to see frequent future use of subscripts and superscripts, in which case <sub> and <sup> could be added to DevBook XML.

in the same file then, to guarantee sequential processing.
</li>
</ol>

</body>
</section>
</chapter>
Expand Down
Loading