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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Dev mailing list Dev@lists.parabola.nu https://lists.parabola.nu/mailman/listinfo/dev