Date: Wed, 09 Apr 2014 15:51:10 -0400 From: Jim Pingle <lists@pingle.org> To: marino@freebsd.org, Christian Weisgerber <naddy@mips.inka.de>, freebsd-ports@freebsd.org Subject: Re: FreeBSD ports which are currently scheduled for deletion Message-ID: <5345A4AE.6020505@pingle.org> In-Reply-To: <53458CF0.4080900@marino.st> References: <mailman.0.1396958400.6606.freebsd-ports@freebsd.org> <5344005C.4030503@aldan.algebra.com> <20140408185537.69d5cd6e@kalimero.tijl.coosemans.org> <53442E10.6060907@aldan.algebra.com> <20140409002033.5a2d9850@kalimero.tijl.coosemans.org> <slrnlkb2do.83i.naddy@lorvorc.mips.inka.de> <53458CF0.4080900@marino.st>
next in thread | previous in thread | raw e-mail | index | archive | help
On 4/9/2014 2:09 PM, John Marino wrote: > On 4/9/2014 19:56, Christian Weisgerber wrote: >> On 2014-04-08, Tijl Coosemans <tijl@coosemans.org> wrote: >>> Then, once it is reasonable to assume that a port is unused it is first >>> marked deprecated which gives users some time to step forward. >> >> There seems to be the general problem, seen again and again, that >> users only learn of a port's deprecation status when it is finally >> removed and not in the preceding grace period. > > I find this highly doubtful. > I will give you that binary package users won't know the package is > deprecated or their is even a problem until the package is no longer > available, but somebody is going to see if if they build from source. > > OTOH, if somebody only rebuilds every 15 months, the deprecation period > could come and go. I guess the ultimate solution is that "pkg info" > shows packages that are deprecated. Could a mechanism similar to portaudit be crafted to warn the user of installed software that is in danger of being deprecated? Or even moved to a new name, or I suppose even if it has significant changes that warrant an UPDATING entry? I'm guilty of not reading my workstation's own nightly periodic output as often as I should but even when I don't read it thoroughly the portaudit part bit gets my attention. portaudit itself could grow the (optional) features or it could be done via some other similar mechanism. Only informing at install time seems like a good way for many things to slip through the cracks. Jim
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5345A4AE.6020505>