On Tuesday 06 March 2018, Ludwig Nussel wrote: > Karel Zak wrote: > > On Tue, Mar 06, 2018 at 10:40:14AM +0100, Ludwig Nussel wrote: > >> I just noticed that agetty gained support for /etc/issue.d. Very > >> cool! > > > > Thanks, according this feedback > > https://github.com/karelzak/util-linux/commit/1fc82a1360305f696dc1b > >e6105c9c56a9ea03f52#commitcomment-27947668 > > > > it seems that /etc/issue.d may conflict with already existing > > solutions in OpenSUSE. Is it true? > > There is a package called issue-generator > (https://github.com/thkukuk/issue-generator) that generates > /etc/issue based on content from /{usr/lib,run,etc}/issue.d. There is > no real conflict, just some partial overlap in features. IMO > issue-generator would be mostly obsolete as soon as agetty reads > those directories itself. > > > I'll probably add --disable-agetty-issued to make it fully > > backwardly compatible. > > TBH I don't think that's necessary. > > >> Are there any plans to extend the way it reads those files to a > >> systemd style layering ie with read only parts in /usr, > >> potentially generated ones in /run etc? > > > > Good idea. > >> Especially the read only part would be interesting. That way > >> distros wouldn't need to ship /etc/isse at all and packages would > >> put their extension in /usr. Ie no interference with admin space. > > > > What is expected semantic (order)? > > > > Note that agetty requires the /etc/issue file, the directory is an > > extension to the file. The file may be empty or symlink. This is > > because "rm /etc/issue" is a way how some admins disable agetty > > output at all. > > Alternative semantics would be to only use issue.d if /etc/issue > does NOT exist. That would assume that if /etc/issue exists, the > admin created it and doesn't want anything else to be displayed. To > display nothing the file could be created with zero size by the > admin. > Packages would then ship their static issue snippets in /usr and > generate dynamic ones in /run. > The admin would then have the option to either > * create custom content in /etc/issue.d that would be interwoven > with what packages provide - or > * create /etc/issue to only have that one displayed Yes this would be nice. There should be a simple way for the *admin* to disable all these issues directories to only show his well-maintained and tested /etc/issue, regardless what other packages are installed now or in the future. To be honest, I don't really like that emergency-critical things like agetty will need to read dozens of files from many different file systems ... just for cosmetical reasons. IMO a 3rd party issue-generator is the better way. cu, Rudi > Distributions would then have to stop shipping /etc/issue in order > to allow the modular approach to take effect. > > > with layering: > > > > - verify /etc/issue (access F_OK -- required) > > - read /etc/issue.d/*.issue > > - read /run/agetty/issue.d/*.issue > > - read /usr/lib/agetty/issue.d/*.issue > > Is issue.d considered agetty specific or are other gettys expected > to follow suit? If the latter I'd omit the agetty subdirectory. > Alternatively for consistency you'd need to use /etc/agetty/issue.d > I guess :-) > The ordering of layer is right. In systemd semantics files take > preference in order, ie if the same file name exists in /etc and > /usr, only the one in /etc would be displayed. > > > use-case: > > - /etc = system specific files > > ... created by the admin. > > > - /run = generated files > > - /usr = installed 3rd party files > > Not just third party, that is where packages put static files, ie the > distribution. So I'd move what we currently have in /etc/issue to > e.g. /usr/lib(/agetty)/issue.d/10-opensuse.issue -- To unsubscribe from this list: send the line "unsubscribe util-linux" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
