Bug 1339769 - Provide a mechanism to set a custom splash screen string
Summary: Provide a mechanism to set a custom splash screen string
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: redhat-release
Version: 7.3
Hardware: Unspecified
OS: Unspecified
Target Milestone: alpha
: ---
Assignee: Lubos Kocman
QA Contact: Release Test Team
Depends On:
Blocks: 1306543
TreeView+ depends on / blocked
Reported: 2016-05-25 19:53 UTC by Ray Strode [halfline]
Modified: 2017-08-31 18:49 UTC (History)
11 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of: 1306543
Last Closed: 2017-01-04 12:17:07 UTC
Target Upstream Version:

Attachments (Terms of Use)

Description Ray Strode [halfline] 2016-05-25 19:53:19 UTC
+++ This bug was initially created as a clone of Bug #1306543 +++

Description of problem:
Normally plymouth is using the pretty name as a the splash screen string.
But currently RHEL has a hack to use the bugzilla product name for the splash screen string.
This is a problem for RHEV, because the bugzilla product name is "Red Hat Enterprise Virtualization Manager", but the splash screen is for the "Red Hat Enterprise Linux Virtualization Hypervisor".

Please either revert the hack or provide a mechanism to specifically set the plymouth splash screen (i.e. by looking for another field in os-release, like PLYMOUTH_TITLE)

--- Additional comment from Ray Strode [halfline] on 2016-05-25 15:51:09 EDT ---

So what I've done is reverted the initial patch and then special cased "Red Hat Enterprise Linux" to strip out its variant (and some dracut gook that's snuck in).  This is probably good enough for now, but it's pretty messy.

What we really need, going forward is a new field in /etc/os-release that we can use wholesale. I don't think it should be called PLYMOUTH_TITLE as suggested in comment 0, since it's not really plymouth specific in any way.  Maybe PRETTY_FAMILY_NAME or something, and if it's not there we should fall back to PRETTY_NAME.

I'll file a separate bug about that.

Comment 1 Ray Strode [halfline] 2016-05-25 19:56:23 UTC
so to be clear, the request is to add

PRETTY_FAMILY_NAME="Red Hat Enterprise Linux 7"

(or something like that) to all the redhat-release packages.

See bug 911553 for the original problem and workaround and bug 1306543 for where that workaround proved inadequate.

Comment 3 Fabian Deutsch 2016-06-09 13:34:33 UTC
Copy-n-paste from bug 1306543


The problem I see is that
FAMILY_NAME and PRETTY_FAMILY_NAME are not covered by the upstream spec:

Maybe we should have a complete story around this, as in:
What do we need to differentiate, and why isn't NAME enough?
How is NAME different from FAMILY_NAME?
What is the difference between PRETTY_NAME and PRETTY_FAMILY_NAME?

Is teh story that FAMILY is something like the product family, and NAME referring to the specific product in a family, i.e.:

Family: RHEL
Name: RHEL Atomic Host

Family: RHEV
Name: RHEV Hypervisor

Family: Fedora
Name: Fedora
Family: CentOS
Name: CentOS
^^ This is awkward

Family: Fedora
Name: Workstation
^^ Makes more sense

Specififc examples:

= RHEV =
FAMILY="Red Hat Enterprise Virtualization"
NAME="Red Hat Enterprise Virtualization Hypervisor"
PRETTY_NAME="Red Hat Enterprise Virtualization Hypervisor 4.0"
PRETTY_FAMILY="Red Hat Enterprise Virtualization 4.0"
VERSION_ID="7.2"     <- We keep RHEL's version, but use RHEV's version in PRETTY

= Atomic =
FAMILY="Red Hat Enterprise Linux"
NAME="Red Hat Enterprise Linux Atomic Host"
VARIANT="Atomic Host"
PRETTY_NAME="Red Hat Enterprise Linux Atomic Host 7.2"
PRETTY_FAMILY="Red Hat Enterprise Linux 7.2"

= Fedora =
NAME="oVirt Node"
PRETTY_NAME="oVirt Node 4.0"
VERSION_ID="7.2"     <- We keep RHEL's version, but use RHEV's version in PRETTY

In the end I am not sure if we benefit from this.


Comment 4 Lubos Kocman 2017-01-04 12:17:07 UTC
Hello team,

I do agree, if we involve some custom fields that only Red Hat ships, we'll diverge even more from upstream.

Closing as WON'T FIX unless there would be part of systemd documentation. Feel free to reopen bug and move it to systemd.

Otherwise I generally agree about the idea, but would use bit different methodology

Layered Product/Base product which is what we use in PDC, Productmd ...


Note You need to log in before you can comment on or make changes to this bug.