Re: On deprecated packages and notifying users

Ionen Wolkens <[email protected]> Tue, 19 May 2026 22:21:11 -0400
Newsgroups	gmane.linux.gentoo.devel
Message-ID	<ag0al-A1PA__fNY7@eversor>
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 one is that last one is 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.

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
signature.asc (application/pgp-signature, 525 B)