Re: On deprecated packages and notifying users

Ionen Wolkens <[email protected]> Tue, 19 May 2026 22:37:44 -0400
Newsgroups	gmane.linux.gentoo.devel
Message-ID	<ag0eeD1AKdLjzXLW@eversor>
On Tue, May 19, 2026 at 10:21:11PM -0400, Ionen Wolkens wrote:
> On Wed, May 20, 2026 at 02:42:53AM +0100, Sam James wrote:
> > Hi,
> > 
> > First, what this *isn't* about: last-riting, things which we all agree
> > need to be removed, and aren't suitable for anybody to use ever.
> > 
> > Sometimes we have packages that most people shouldn't be using anymore,
> > but they were commonplace once:
> > * net-misc/dhcp (use kea, but kea isn't suitable for everybody)
> > * net-misc/ntp (use another time sync daemon)
> > * sys-kernel/genkernel (on life support)
> > * sys-apps/haveged (largely obsolete w/ modern kernels, see hanno's
> > remarks [0])
> > 
> > I'm sure there's more but these are the examples that came to mind.
> > 
> > We often update the wiki page, inform users of this on IRC/forums/MLs,
> > and may refer to it on bug reports, but it's very easy for people to
> > miss such developments I'd say from experience with breaking the news.
> > 
> > Should we have some way to inform users of this?
> > 
> > Some options:
> > * Last-riting these would be excessive, at least for some cases (ntp is
> >   debatable).
> >   
> > * ewarn in pkg_postinst with some revbump to propagate that. I fear this
> >   may be seen as antagonistic or rude to upstream developers.
> >   
> > * package.deprecated is currently used for developer-facing issues,
> >   where one should inform upstream about a rotting dependency or
> >   similar. Too noisy for users right now.
> > 
> > * Extended p.mask with no removal date.
> 
> One downside with that last one is that if we *do* want to
> last-rite it eventually, may come as a surprise given users that
> didn't let go will have already unmasked it and won't see a new
> last-rite mask message.

A notice in the initial mask massage that they could be removed from
::gentoo anytime without additional warning could be enough, albeit
it does make it sound like a last-rite with an unspecified date.

> 
> This will notably be a problem when I want to remove permanently
> masked legacy nvidia-drivers versions, albeit I did give a rough
> estimated removal date (which spawns several years), nag about it
> in postinst (semewhat visible given users rebuild every kernel
> upgrades), and documentation advise against using too. *Hopefully*
> nobody will be surprised when they wake up one day and they were
> removed from the tree without a new warning.
> 
> (in case of nvidia-drivers, I wouldn't do a simple deprecation given
> they are also rather insecure, so a mask with a notice about that feels
> more fitting either way).
> 
> > 
> > I think I like the last option best, and I'm not sure this issue
> > justifies having a package.deprecated.users (a name I made up, we can
> > bikeshed that if we want to go that direction).
> > 
> > Thoughts? Any other ideas?
> > 
> > [0] https://www.openwall.com/lists/oss-security/2026/05/19/4
> > 
> > sam
> -- 
> ionen



-- 
ionen
signature.asc (application/pgp-signature, 525 B)