Re: jessie-updates gone
Le mar. 2 avr. 2019 à 15:09, Matus UHLAR - fantomas
<uhlar@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.
Reply to: