[Dev] problems with replacements for blacklisted packages

[bill-auger]

On 12/22/2017 06:05 PM, Isaac David wrote:
> the idea is to get rid of replacement info in blacklist.txt

to this i want to add again that this single line  of explanation in the
blacklist.txt is in most cases the only documentation of why the package
is blacklisted and what are the remedies - so this would make it even
more imperative that the blacklisting process be fully documented


On 12/22/2017 10:06 PM, Luke Shumaker wrote:
>  - have libre/b43-tools provides=() and conflicts=() b43-fwcutter, but
>    not replaces=()

just to point out again what i learned from reading the archwiki on the
topic of provides vs. conflicts vs. replaces that this suggestion is not
in line with the original intention - not to say that it is necessarily
a bad thing but when making a break from convention it is wise to be
aware that it is a break from convention - e.g. the semantics of
provides vs. conflicts vs. replaces in any packages from upstream are
different from how parabola uses those lists - but more importantly that
these are not intended to be informational in the way being described
here - these attributes are functional and trigger specific behaviors in
the package management tools

to re-iterate the semantics as the upstream describes it:
* 'provides' - is used for dependency checking - multiple packages may
'provides' (and therefore satisfy) the same dependency and any number of
them may be installed at the same time
* 'conflicts' - is used for conflict resolution - at most one
conflicting package may be installed at any time - if you try to install
a conflicting package then the package manager will ask to remove the
one that is installed
* replaces - is the important one for this discussion - according to the
docs, when any new package is added to the repo that states that it
'replaces' another, it has the definite, immediate, and specific effect
of forcefully removing the specified package from any user's system, and
 without asking (i think), and replacing it with the new replacement
package - this happens the next time that the user `pacman -Syu` and it
may even ignore any "hold" on the old package - this was intended to be
used only for emergencies if, for example, some malware got into the system

again im not saying that breaking convention is bad but if the package
manager has these specific behaviors triggered by these lists care must
be taken to ensure that the new semantics have no unintended practical
side-effects

if the suggestion here is for parabola to use the 'replaces' attribute
for some purpose other than what is described above it may be instead a
better idea to introduce a new list such as: 'libre_replaces=()' that
pacman will ignore

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <https://lists.parabola.nu/pipermail/dev/attachments/20171223/e2d05d9e/attachment.sig>