Re: jessie-updates gone
Le mer. 3 avr. 2019 à 12:44, Jonas Meurer <jonas@freesources.org> a écrit :
> Informing users about ending security support (e.g. by local
> notifications) could definitely be improved - but that's a separate topic.
>
We should definitely fork this discussion into a new subject. However
I wonder if it should be created into debian-lts's mailing list or if
it exists a more appropriate list for discussing about this kind of
conceptual improvement of Debian packaging subsystem and life-cycle
handling ?
In the meanwhile, here are some of my thoughts and comments.
Le mer. 3 avr. 2019 à 12:25, Matus UHLAR - fantomas
<uhlar@fantomas.sk> a écrit :
> On 03.04.19 09:54, Jan Ingvoldstad wrote:
> > c 3) when requesting installation of unsupported packages, provide a
> >warning
> >
> >For c 3), this could be similar to when e.g. apt/apt-get pauses to ask
> >due to dependencies, and overridable with the same options.
> >
> >However, as Pierre says, this is quite a bit of extra work for package
> >system developers/maintainers.
>
> I hope that's what we discuss here ;-)
Yes, precisely. I admit I went over the current situation of Jessie,
who's already part of a past situation in my mind, and started to look
forward at where we could head to for next (next) time. I was at first
very enthusiastic at adding a "not to remove stretch-updates/" mention
to the procedure when Stretch will enter LTS, but I now fell some more
could be devised to better handle the situation.
I usually look far ahead, then work backward to connect the dots. My
thoughts was directed for Debian Bulleyes at best, and maybe to the
next one. Currently Debian Stretch is stable and thus (almost) settled
in stone (to be clear, this is not a criticism but relate a fact about
a feature I truly appreciate). Buster, for his own, has entered the
freeze state, so we can also consider it almost settled in stone. So
thinking about improving how Debian handle all this fast bring us to
Debian Bulleyes or Bookworm.
With this scope in mind, and thinking far ahead with something like a
blank page, and the opportunity to add code where required, I believe
theses actual considerations would deserve a well thought design to
support spot on all the conceived edge cases.
Le mer. 3 avr. 2019 à 12:25, Matus UHLAR - fantomas
<uhlar@fantomas.sk> a écrit :
> >On 2019-04-03 02:02, Andy Smith wrote:
> > c 2) a transition into LTS should probably be accompagnied with a
> >default run of check-support-status
>
> maybe create new point release where base-files depend on
> debian-security-support
If the maintainers (or the LTS team) would accept to modify the
dependency tree, this could help on the already stable and frozen
releases. Nonetheless, if I understand how packages are upgraded,
wouldn't it requires the download and reinstall of theses essential
packages (because of the version-number bump). This doesn't seems very
elegant. And I must add that I'm not very found of this as it would
change dependencies on the base packages. I would tick at seeing such
kind of essential packages being updated. Moreoever this would be not
for technical reasons but for organisational reasons.
Would I stumble upon this notification, I would wonder what have
happened to the base package being modified during the course of the
life-cycle of a released and stable version of Debian. IMO, this
doesn't fit much with the philosophy of Debian not to touch anything
in the release once being tagged stable. Except of course for security
updates and other very important updates. Would this kind of update
you suggest, it probably would have brought me to post something on
debian-user's mailing list to try to understand what have happened.
Le mer. 3 avr. 2019 à 12:25, Matus UHLAR - fantomas
<uhlar@fantomas.sk> a écrit :
>
> >On 2019-04-03 02:02, Andy Smith wrote:
> >
> >>c) if getting warnings from "apt update" does seem to be an
> >> effective final way to reach such users, would it be a good idea
> >> to find a way to have apt tell them about their transition into
> >> LTS?
>
> On 03.04.19 09:54, Jan Ingvoldstad wrote:
> >So, sort of a variant on Pierre Fourès's suggestion?
> >
> >I like that.
>
> I agree.
> It's better to warn than error, better when LTS starts than year later.
>
> Just note that expiring the archive is something to consider - people who
> put 'Acquire::Check-Valid-Until "0";' into their configs may forget it
> there, so they will miss such warnings within next release cycle.
To my view, I think the best could be to add meta-informations into
the packaging subsystem, and this on two level of scope. One would be
repository based, the other would be package based (but wouldn't be
stored in the packages but as per-package meta-informations in the
repositories).
For the package-based meta-information, for the Debian Team (might it
be the mainteners team, the security team, the LTS team), or for the
not affiliated ELTS team, or for any organisation running a repository
compatible with Debian distributions, it would be nice to add some
kind of flag to spot the package being deprecated, bug-unmaintained,
and/or security-unmaintained. Writing so I wonder if there should be
any difference between the concepts mentioned here. I feel there could
be but this doesn't need to be clarified for now. Also, this flags
should probably be defined in conjunction with a « date to effect ».
The repository-based meta-informations would work likely the same,
with the notable addition of flags like « in LTS », « in ELTS » and «
archived ». This way, the Debian Teams could advertise users directly
through apt (and the like) about the future depreciation of a
repository (like the backports), and/or its removal from the main
mirrors towards the archive. For me, this would require two different
flags, as this is two different concern. One being about the
maintenance and security aspect of the packages, the other being about
to have plenty of time in advance to update the sources.list in order
not to encounter any error while making an update (or while
reinstalling an instance of an old version of Debian, like I'm doing
right now for a software stack not yet tested/approved on Stretch).
This way, announcing some month before that codename-updates will be
removed from the main mirrors let sys-admins plenty of time to update
their instances. All this directly « pushed to the users » and without
having them read the announcement. For more details, the warning could
refer to the corresponding announcement. On the same level, Debian
could announce through theses warnings some months before that the
distrib would enter its LTS phase, or its ELTS phase, or would be
definitively archived. With the warning being printed out on each use
of apt, this would dramatically improve the sys-admins « user
experience » not to miss on an important change who might impact them
sooner or later.
On a technical point of view, as mentioned by Matus,
check-support-status could embrace this role, or part of it. It could
maybe be invoked as a prerequisite of all normal invocations of apt
(and friends). However, I would add an exception to this rule in the
form of doing it as a post-step when invoking apt-get update. It would
there benefits from the updated information from the repositories.
On an organizational point of view, not to overload the work of the
different teams, something could be devised to group the publication
of an announcement to the mailing list with the update of the
meta-information in the repositories. This could also be taken as an
opportunity to better formalise and automate the bump and jumps in the
life-cycle of the distribution.
Then, once the flags and warning would have been devised, would come
the time to design the proper solution on how to silent the warnings.
It clearly must be more fine grained than 'Acquire::Check-Valid-Until
"0";'. BTW, I realize the envisioned solution would probably supersede
the use of this flag. I would see it repository based and package
based, like the flags, but (as a future future improvement) I would
also see it able to handle some kind of grouping. Somehow I would
enjoy some mechanism to group select some warning silencing. One
approach could be to silent one package and all its dependencies. This
could be devised in order to select the direction of the dependency. I
would for exemple want to silent the warning for jdk8 from the
backports of Jessie in order to run Jenkins, so it would silent
forward dependencies. One could also want to do it the other way
around. While in need of a specific package, requiring some other not
maintained package, silencing the head of them would silent the
others. Other grouping mechanisms could be devised.
Moreover, I think the silencing configuration should be able to target
some specific revisions or provenance (origin) of the packages.
For example, one package in the main repository could be maintained,
while the one in the backports would not be maintained. Imagining I
would silence the offending package, then later would I find a way to
fall back on the maintained one in the LTS, but forget to remove the
silencing directive. Then again, in ELTS, this previously
maintained-in-lts package, the version from the main distrib, would
not maintained anymore. A warning should definitively pop ups for this
edge case as this is new information about a new deprecation. Versions
and/or origins must then be tracked and selectable when silenced.
An other example would be the handling of distribution upgrading to a
next release. The configurations should be specific to packages
related to the base distribution version, or to be more explicit, to
where they come from (was it from jessie, from jessie-backports, or
from stretch). For exemple silencing of jdk8 in jessie-backports
should not propagate to silencing the eventual warning of not
supporting jdk8 in a future LTS or ELTS of Stretch. This would be a
different situation and this new situation would deserve a new warning
by its on.
To silent warning on packages, this would thus be advisable to use a
tuple with some of the codename of the distribution and/or the origin
where the package comes from (ie. backports), then the package
identifier and perhaps the version number of the package.
Of course, all this need a lot more thoughts to put in it. This is
just a first scratch of the problem.
Le mer. 3 avr. 2019 à 09:54, Jan Ingvoldstad
<jan-debian-lts-2014@oyet.no> a écrit :
> c 3) when requesting installation of unsupported packages, provide a
> warning
I would also personally add
c 4) when invoking the package manager, warn (ofr the ones not being
silenced) for each package being unsupported or for each announcement
about a configured repository.
In some way, while in LTS or ELTS, one package could suddenly leave
the scope of the supported packages. I think it would be nice that a
simple apt-get update would advise me that package XYZ, the one I
event didn't remember about, will soon turn (or has already turned)
unsupported at a specific date.
With that being well defined, would incur more forward freedom on how
to handle the different repositories, like which might be disabled,
decommissioned, introduced and the like. This decisions could even be
taken after the freeze and the release of the version. It could even
be taken while in LTS to announce the not initially envisioned ELTS,
for example. Or to set up dedicated repository for LTS in order to
mark a sharp transition between the standard maintenance of the
oldstable and the LTS phase. And all this could be
improved/reorganized while in the life-cycle of the distribution
without incurring a single error message to sysadmins who at least
periodically updates their instance of their installation procedures.
Then, with a design agreed by the community and being developed for
the futures versions of Debian, would then come the opportunity to see
what can be done in this sight with the already settled in stone
versions of Debian.
Of course, this would takes years to see this come live, but I think
this could definitively worth it. Time will pass anyway. Bulleyes and
Bookworm will eventually became the stable version of Debian and then
jump in oldstable and then in LTS. I would be nice by then to have a
clear and crisp solution to handle this use cases.
Cheers,
Pierre.
Reply to: