Le mar. 2 avr. 2019 à 15:09, Matus UHLAR - fantomas <uh...@fantomas.sk> a écrit : > > >> On 4/1/19 8:14 PM, Andy Smith wrote: > >> >I do understand that re-adding an empty jessie-updates directory > >> >will silence a lot of warnings from apt update, and thus would avoid > >> >the questions from end users that I have seen in a lot of places, > >> >but… I can't help thinking that although it is bad that these users > >> >were confused, at least they now understand that the level of > >> >support has changed. > > >On Tue, Apr 02, 2019 at 11:53:50AM +0200, Miroslav Skoric wrote: > >> -1 > >> > >> Programmers' decision that led thousands of users to ask themselves what > >> was > >> wrong with their apt update was a very bad marketing for Debian. > > On 02.04.19 10:59, Andy Smith wrote: > >The alternative is that those users continue using Debian without > >realising that their packages stopped being supported by the > >maintainers and security team and are now supported by LTS alone. > > this should happen when LTS is over, not before. > also, there's check-support-status for unsupported packages. >
I personally understand the both points of view. If nothing had occurred, I would have left things running thinking I'm all covered up. It's nice I learnt so much about this. My major eye-opener was the situation about the backports being deprecated. But at the same time, I have many servers (including many virtual instance) where apt-get went broken. I also have automated install scripts (not yet moved to stretch) who need to be modified and re-tested. This is not a major thing to fix, but this will take some time nonetheless. And I'm very glad this happened while I was not in an emergency, required to reinstall something as fast as possible. I think it could be nice to be able to avoid unnecessary fiddling on the servers. Especially when these kind of changes might impact a lot people. This is maybe more work involved, or this might not be doable for reasons I'm not aware, I don't know, but why not even keep [distrib]-updates up-and-running (as its intended use) ? While in LTS, the security updates would still go to the security repository, and non-security updates would go to the stable-updates/ repository. This would incur no conceptual mess about what's happening or not. For standard usage, on supported architectures, all would goes smooth, as one could expect. For my share, I would have been warned about the backports being deprecated and moved to the archives and would have been happy for the rest staying up and running (as I already knew Jessie was in LTS, with all the consequences it implies). On a more preventive level, we could keep [distrib-updates] running, and then shutdown the security repository to explicitly show the security team has ended its work, and then create a new repository dedicated to the LTS support. The ones wanting to jump in the LTS phase would do it consciously and explicitly. However the transition wouldn't be smooth as it would incur a lot of error messages. This is in some way how it works for ELTS on Wheezy. It also could be achieved more smoothly like with adding some flags on the repository and that apt-get (and friends) bring a warning to the console while proceeding the update. This warning could then be silenced through setting a flag on the concerned instances (like I did for the backports with 'Acquire::Check-Valid-Until "0";'). This would require more work involved and would need more time to propagate. But I believe this could be a nice working mechanism for the future of Debian. This warning mechanism could even be extended to help prevent situations like the following one. Since the deprecation of the backports, I had half a year to take into notice about the consequences, and then, act. I just didn't was aware of it (my fault, nonetheless it's not easy to follow everything, meaning read every announce and not skip over the one of them). Would my instances throws at me some warning like : "jessie-backports will be deprectated on July 25 2018" some month before it occurs, and then something like "jessie-backports has been deprecated since July 25 2018" would have been of great value for me. And this could be applied the same way for security transitioning to LTS. What would be even greater with this warning mechanism would be to have more overlap while the repositories are shutted down or moved to the archives. I imagine something telling me "jessie-backports has been deprecated since July 25 2018, jessie-backports is now avaible on http://archive.debian.org/, jessie-backports will be removed from the main mirrors on Mars 20 2019" some months before it accutally occurs. I thus would have had the time and set my own schedule to decide when to fiddle with /etc/apt/sources.list without causing any error on my instances. Of course, this could also be translated to something like that for the stable-updates or the security updates. I guess this is a very long term project as it is directly linked to the release cycle of Debian version, and as it implies deep modifications (like to update most if not all package-manager tools and also the repository format to piggy-back theses informations) but I would really like to see it turn live someday. This could really help to improve the « user experience » of the system administrators of long-running debian instances. I don't have much hours to offer on this subject for now, and I guess it's more a kind of task for very long term contributors of the distribution, but I would enjoy to spend some cycle on the years to come on helping this subject turn live if this idea seem sound. Regards, Pierre.
