Michał Górny posted on Sat, 06 Jan 2018 00:55:58 +0100 as excerpted: > W dniu pią, 05.01.2018 o godzinie 23∶09 +0100, użytkownik Kristian > Fiskerstrand napisał: >> On 01/05/2018 10:28 PM, Aaron W. Swenson wrote: >>> On 2018-01-05 15:16, William Hubbs wrote:
>>>> If we have a default expiration, it should be one year after the >>>> date posted to go along with our current policy of not supporting >>>> things that are older than a year. >>> >>> I thought it was three years. AFAIK, the one-year policy is on upgrades-from. If a user hasn't synced and updated in a year, updating is likely to be "problematic", and may require techniques such as digging old tree states a year or so apart out of git and using those to update a year's worth of updates at a time, and/ or updating the system in increments, the few packages that will update successfully first, then trying again to get the ones that can now update due to the improved base of the first set, and again... It helps if there's other systems you keep more current, so you've already dealt with most changes one or a few at a time. I know this from experience as while I keep my main system current (I'm antsy if it's more than a week between syncs), I used to have a 32-bit- only first-gen atom, that I built updates for in a chroot and synced over, that I'd sometimes go over a year between updates on. (Personal policy was nothing private on that machine, and it was normally not internet connected, so I wasn't horribly worried about security.) So over a year, while the above update method is normally still /possible/, the easier/recommended/supported method is simply using the old install to fetch a new stage-3 to a chroot, and install new to it, except that you can "cheat" by basing your new config including USE flags, etc, off the old one. The 3-year may well be for individual packages, but all I've ever seen for the entire tree and full system update is 1 year. >>> At any rate, I think a year is too short. >>> >>> How about 18 months? That seems a reasonable default... >> I might sound like a broken CD here, but why define the expiration as >> part of the news format instead of specifying it in the package manager >> as a user defined variable? Various use cases requires different >> treatment, so leaving it up to user seems more relevant to me, and we >> could allow information to be presented as part of stages to give a >> hint for what dates to look for? >> >> > To be honest, I kinda agree with Kristian here. I feel like this header > isn't going to work well. > > While the idea may initially sound good, I'm afraid we'll have the usual > developer split here: some developers will set very long times, some > will set very short times, some will not care and just copy some random > value (default, the value from some other news item). In the end, users > will end up seeing very old news items from dev X, while newer items > from dev Y will disappear. > > So yes, I think having a single predefined time is better, > for consistency at least. And allowing user to adjust that time based on > his own is certainly better than making it only dev-settable. $ equery b news.eselect app-admin/eselect-1.4.10 (/usr/share/eselect/modules/news.eselect) So in that case it's not the PM, but eselect. But a new eselect version that ships a default /etc/eselect/news/expiry that looks something like this: # Days after which unread news messages will no longer be shown # Default is 548, 18 months, (365*1.5 rounded up) expiry=548 ... and which then looks there for the value, seems reasonable to me. * Being in /etc the file would be subject to normal config-protection. * Can be accomplished with a bit of code and simple eselect package version bump, presumably with a post-install message mentioning the new config option. No need for all the bureaucracy of a GLEP update, etc. * Handbook and etc. documentation that I believe already mentions news and suggests eselect news as the default reader can be updated to mention this config option as well. * A news item announcing the new default expiry and config for it might be appropriate as well. * Should that general approach be agreed, all that would remain to debate would be whether 548 days (365*1.5 rounded up) is appropriate. The precise config file path, name and format would be up to the implementer and/or eselect news module maintainer. * Other news readers could of course set and ship their own default expiry, if desired. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
