Hi, Maxim Cournoyer writes: >>> You are changing the public API rather drastically. You need >>> to >>> come up >>> with a mechanism that will warn & automatically rewrite the >>> legacy >>> form >>> to the new form in the meantime, which I'm afraid won't be >>> trivial >>> given >>> the disruptive overhaul. There are examples among other >>> services; >>> it >>> typically involves defining a man-in-the-middle field >>> sanitizer that >>> takes the old value, updates it to the new expected one while >>> emitting a >>> deprecation warning. >> >> Done. It should be noted that it is impossible to cover all >> possible >> cases >> to provide solid backward compatibility. Uses of file-like >> objects >> increase variations. > > OK; so the new version will need some fiddling from users to > just build > with their current config? Or are these expected to be rare > edge cases? Problems may occur with complex setups, where commands provided by users are very different from "bash -l". Knowing in advance all alternatives is impossible. Everything sane or default, should work as is, showing the warnings on reconfigure. >>> Looks like all the tables can use '@table @code' instead of >>> @asis, >>> then >>> you can remove all the @code decorators for each items. This >>> could >>> be >>> done in a prior commit. >> >> I didn't find any use of '@table @code' which document default >> values. > > See (info '(texinfo) @table): > > Write the ‘@table’ command at the beginning of a line, after > a blank > line, and follow it on the same line with an argument that is > an > 'indicating' command, such as ‘@code’, ‘@samp’, ‘@var’, > ‘@option’, or > ‘@kbd’ (*note Indicating::). This command will be applied to > the text > in the first column. For example, ‘@table @code’ will cause > the text > in the first column to be output as if it had been the > argument to a > ‘@code’ command. > > I think the 'indicating' command argument to @table is required, > so > there is no default value. I have to try, may be next time. You want me to update all tables in greetd service documentation? >>>> - (sleep 1) ;give seatd/logind some time to start >>>> up >>> >>> That's a suspicious line which already existed. It looks >>> fragile. >>> Is >>> it really necessary? >> >> Unfortunately, there is no good/easy way to conditionally >> depend >> on elogind or seatd. greetd-service-type and agreety greeter do >> not >> require >> seat, only sway based greeters may/will want it. > > I meant perhaps waiting 1 second here is no longer necessary? 1 > s is > not much at all. Perhaps added during debug/development of the > service > and forgotten? I'd trying taking it out and see. Unfortunately, if you take it out, you will end up with race condition when sometimes it works sometimes not. Technically, "sleep 1" may cause race as well, but for years I didn't have any issue with it. To try it, you have to configure seatd, greetd, and sway based greeter. Then just reboot/restart host until race. One possible is to provide additional greetd configuration that will expose the shepherd requirements. But I think it might will complicate configuration dramatically for end user.