You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As is currently stands, the only way to signal a breaking change in an update is to mention it in INSTALL.msg. This shows the message for any updates, and even for fresh installations. On top of that, messages relevant to only a fresh installation are shown for updates too.
The result is that most messages shown in an average transaction aren't relevant in any way to the transaction, which causes users to learn to tune out the messages.
I propose adding messages that are specific to an update (or rather, specific to a breaking change), and changing the existing INSTALL.msg to be only shown for fresh installs or reinstalls.
This would require storage of the update messages, along with the package version containing the breaking change. One such update message would only be shown if the package is being updated, and if the currently installed version is lower than the message's version. XBPS should be able to show as many update messages as relevant to a particular transaction.
The logic for when INSTALL.msg is shown would be changed to not show the message for updates.
I'm not familiar enough with XBPS internals to know what would need to change implementation-wise.
On xbps-src's end this would probably look like additional UPDATE-<ver>.msg files in a package's directory, along with changes in the xbps-create invocation. A good number of packages would need to be updated to use UPDATE messages.
EDIT: I realised a big flaw in my pick of what version should be recorded along with an UPDATE message, so I switched it to be the first version that breaks (message shows for any currently installed version lower than it).
The text was updated successfully, but these errors were encountered:
As is currently stands, the only way to signal a breaking change in an update is to mention it in
INSTALL.msg
. This shows the message for any updates, and even for fresh installations. On top of that, messages relevant to only a fresh installation are shown for updates too.The result is that most messages shown in an average transaction aren't relevant in any way to the transaction, which causes users to learn to tune out the messages.
I propose adding messages that are specific to an update (or rather, specific to a breaking change), and changing the existing
INSTALL.msg
to be only shown for fresh installs or reinstalls.This would require storage of the update messages, along with the package version containing the breaking change. One such update message would only be shown if the package is being updated, and if the currently installed version is lower than the message's version. XBPS should be able to show as many update messages as relevant to a particular transaction.
The logic for when
INSTALL.msg
is shown would be changed to not show the message for updates.I'm not familiar enough with XBPS internals to know what would need to change implementation-wise.
On xbps-src's end this would probably look like additional
UPDATE-<ver>.msg
files in a package's directory, along with changes in thexbps-create
invocation. A good number of packages would need to be updated to use UPDATE messages.EDIT: I realised a big flaw in my pick of what version should be recorded along with an UPDATE message, so I switched it to be the first version that breaks (message shows for any currently installed version lower than it).
The text was updated successfully, but these errors were encountered: