On Wed, 27 Jun 2012, andre999 wrote: > nicolas vigier a écrit : >> On Wed, 27 Jun 2012, andre999 wrote: >> >> >>> nicolas vigier a écrit : >>> >>>> On Wed, 27 Jun 2012, andre999 wrote: >>>> >>>> >>>> >>>>>>> I would favour tagging backports as update repos, so that in the event >>>>>>> of a newer backport for security or bug fixes, that it will be >>>>>>> automatically presented with other updates. >>>>>>> >>>>>>> >>>>>> No. >>>>>> as the update applet currently works it would show the backport as >>>>>> an update even if you dont have an earlier backport installed, >>>>>> defeating the purpose of having separate /updates vs /backports >>>>>> >>>>>> >>>>> This is conditional on first modifying the update tools, as suggested >>>>> next. >>>>> A backport should only update an already installed backport. >>>>> (Similarly for nonfree and tainted, if that is not already the case.) >>>>> >>>>> >>>> We should not change the behaviour of medias tagged as update repo. If >>>> we want a different behaviour for backports then we should tag those >>>> medias as backport, not update. >>>> >>>> >>> The idea is, once the tools are appropriately adjusted, to tag the backport >>> repos as update media, as in rpmdrake. But alternately we could get the >>> update tools to automatically treat backport repos as update media for >>> backports. >>> >> backports are not updates, why should we tag them as update ? >> > If you are talking about the packages themselves, of course _backports > packages_ should be tagged as backports, and regular update packages as > updates.
packages themselves are not tagged as backports or updates. > However talking about _backport repos_, exactly how we tag them is > arbitrary. > Although obviously backports are updates relative to the initial release in > question, so it is not unreasonable to tag the backport repos as updates. backports and updates repos need to be handled differently by urpmi/rpmdrake. So they should be tagged differently. Is it so hard to understand ?
