andre999 wrote: > blind Pete a écrit : >> andre999 wrote: >> >> >>> blind Pete a écrit : >>> >>>> andre999 wrote: >>>> >>>> >>>> >>>>> blind Pete a écrit : >>>>> >>>>> >>>>>> Samuel Verschelde wrote: >>>>>> >>>>>> >>>>>> >>>>>> >>> >> [snip] >> >>>>> - Functioning as an update, it would only replace already installed >>>>> backports, once the tools are appropriately adjusted. >>>>> >>>>> >>>> There are a couple of ways to do that. The simplest that I can think >>>> of is to split "backports" into "backports" and "backports update". >>>> Allow cherry picking from "backports" and apply "backports update" >>>> automatically. >>>> >>>> >>> I was thinking of cases where the user chooses to "update" their >>> system. New versions of backports already installed would be presented >>> as updates, along with those from the update repos. >>> Just as we don't have any update-update repos, it wouldn't make sense to >>> have backport-update repos either. >>> >> [snip] >> >> It depends on how you look at it. >> >> If you consider non-free, tainted, and backport to be optional >> and any update package to be highly recommended if and only if >> the corresponding package is already installed. Then is does >> not matter if the old package is a tainted.rpm, nonfree.rpm, >> bp.rpm, or an ordinary rpm. Just one way to look at it, not >> the only way. >> >> > But how is it possible to distinguish a priori between a backport which > will be an update and one which will be a "new" backport on a users' > system. It would only be an "update" if the user has already installed > the corresponding backport on their system.
If the rpm is tagged, either internally or just by having "bp" in the file name you can tell if it is a backport. If a new package has the same name - including the "bp" part - but a higher version number, install it, else, just list it as available. Or they could be kept in different places. > If the fact it is a backport is ignored, then every backport would be, > by definition, an update. Even packages newly imported to Mageia. ??? I meant that the logic for dealing with a bp-update would be the same as for nonfree-update and tainted-update (and I suspect, update itself). Re-use existing code. > To me, a "corresponding" package is one from the same category, > according to whether is is backport or not, and according to whether in > "core", "nonfree", or "tainted". > To consider otherwise is to deny the importance of these categories. Catagories multiply here, not add, you have listed six, not four. > Backports are considered separately because they are much more at risk > to not function properly, since they weren't tested with the rest of the > release, being added afterwards. So we have to be much more careful > about adding them. The last thing we want is for the backports to be > included automatically with updates, even if the user had not already > decided to install the corresponding backport. Installing a backport > should be an exceptional, explicitly decided activity -- except when the > user has already decided to install the corresponding backport, when it > is useful to present newer versions as updates. They are likely > security or bug fixes. I think that we are in agreement.
