On 1/2/24 3:22 AM, Ulrich Mueller wrote:
>>>>>> On Tue, 02 Jan 2024, Eli Schwartz wrote:
> 
>> +++ 
>> b/2024-01-02-separate-usr-now-requires-an-initramfs/2024-01-02-separate-usr-now-requires-an-initramfs.txt
> 
> The short-name is rather long. GLEP 42 strongly recommends to stay below
> 20 characters:
> https://www.gentoo.org/glep/glep-0042.html#news-item-identities
> 
>> +Title: Separate /usr now requires an initramfs
>> +Author: Eli Schwartz <eschwart...@gmail.com>
>> +Content-Type: text/plain
>> +Posted: 2024-01-02
>> +Revision: 1
>> +News-Item-Format: 2.0
>> +Display-If-Installed: sys-apps/baselayout[split-usr]
> 
> This is not a valid header. (Format 2.0 doesn't have Content-Type.)


Thanks, I was too hasty in my double-checking -- I fixed all 3
formatting bugs locally.


>> +In 2013, Gentoo policy determined that separate /usr without an initramfs 
>> was
>> +officially no longer supported:
>> +
>> +- https://projects.gentoo.org/qa/policy-guide/filesystem.html#pg0202
>> +- 
>> https://gitweb.gentoo.org/data/gentoo-news.git/tree/2013/2013-09-27-initramfs-required/2013-09-27-initramfs-required.en.txt?id=a79dd69b0cca439bc0c483c9193c79e0554819d0
> 
> The 2013-09-27-initramfs-required news item already said:
> 
> | Linux systems which have / and /usr on separate file systems but do not
> | use an initramfs will not be supported starting on 01-Nov-2013.
> |
> | If you have / and /usr on separate file systems and you are not
> | currently using an initramfs, you must set one up before this date.
> | Otherwise, at some point on or after this date, upgrading packages
> | will make your system unbootable.
> 
> It is also in the Handbook since 2014:
> https://wiki.gentoo.org/wiki/Handbook:AMD64/Installation/Kernel#Optional:_Building_an_initramfs
> 
> What has changed that we would need another news item?
> 
> Ulrich


As Sam said, the idea is to give people a heads up that they have to do
something to adapt -- given it's been 10+ years, it feels a bit not-good
to suddenly carry out the original promise without warning. This is a
good reason why when something is promised, it should actually be done
on schedule...

Given everything was already decided and signed off on, there's no need
to rehash whether or not to do it. We can just do it. But users should
get a heads up that there is something they need to do to ensure their
system will be working -- and 10+ years is simply too much of a gap
between the time of the news and the time of fulfillment.


-- 
Eli Schwartz


Reply via email to