Le mer. 3 avr. 2019 à 12:44, Jonas Meurer <jo...@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 <uh...@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 <uh...@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 <uh...@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-2...@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.