Quoting Ivan Shmakov (2013-07-09 12:59:01) > >>>>> Justus Winter <4win...@informatik.uni-hamburg.de> writes: > > > This is essentially the same as > > 89f6476d8979174f395a1bf784486254464c349d but fixes the existing > > /etc/inittab file in the postinstall script. > > […] > > > + * sysvinit.postinst: Fix getty path in /etc/inittab on Hurd. > > Please note that the GNU Coding Standards recommend to use the > “file name” term here instead: > > --cut: https://www.gnu.org/prep/standards/standards.html -- > Please do not use the term “pathname” that is used in Unix > documentation; use “file name” (two words) instead. We use the term > “path” only for search paths, which are lists of directory names. > --cut: https://www.gnu.org/prep/standards/standards.html -- > > (The last component of a file name — that is, a file name > without the leading directories — could then presumably be > called “base name.”) > > […]
Noted, thanks. > > +if [ "$(uname)" = GNU ]; then > > + sed -i -e 's|/libexec/getty|/sbin/getty|' /etc/inittab > > I don’t seem to understand. Shouldn’t it be the other way > around? > > But overall, I doubt that this change is necessary. If the > package is being upgraded, the chances are that this defect was > already corrected by the user. And for the new installations, > wasn't this issue already fixed? Yes, it is fixed for new installations. However, the inittab as shipped with the package is only installed as /etc/inittab if this file is non-existant. As the inittab file was formerly not used on Hurd systems, it is likely that users that are upgrading are not aware of this issue, and not fixing that renders the system somewhat unusable. I'm aware that sed'ing around in the file is probably inappropriate, maybe we should just display a message instead? Justus
signature.asc
Description: signature