| View previous topic :: View next topic |
| Author |
Message |
Skippy204
Guru
Joined: 09 May 2008
Posts: 348
Location: Colorado, USA
|
 Posted: Thu Dec 25, 2014 4:35 am Post subject: "runscript is deprecated; please use openrc-run instead |
 |
|
| Code: |
runscript is deprecated; please use openrc-run instead.
|
I get many of those during the boot process and I figure it's time to stop ignoring them and do something about it before I break something.
What I've figured out on my own is that runscript appears to be called by assorted scripts in /etc/init.d/
Such as this one:
| Code: |
root # cat cupsd
#!/sbin/runscript
depend() {
use net
need dbus
before nfs
after logger
}
start() {
ebegin "Starting cupsd"
checkpath -q -d -m 0775 -o root:lp /var/cache/cups
checkpath -q -d -m 0775 -o root:lp /var/cache/cups/rss
checkpath -q -d -m 0755 -o root:lp /run/cups
checkpath -q -d -m 0511 -o lp:lpadmin /run/cups/certs
start-stop-daemon --start --quiet --exec /usr/sbin/cupsd
eend $?
}
stop() {
ebegin "Stopping cupsd"
start-stop-daemon --stop --quiet --exec /usr/sbin/cupsd
eend $?
}
|
What is the correct way to convert all of these calls for runscript over to calls for openrc-run. If indeed that's "all there is to it"?
Thank you much. |
|
| Back to top |
|
 |
mv
Watchman
Joined: 20 Apr 2005
Posts: 6780
|
| Posted: Thu Dec 25, 2014 10:32 am Post subject: |
|
|
Yes, changing the shebang is "all there is to it": The renaming is only to avoid collision with other init systems.
Oh, not quite: You should also file bugs for all gentoo packages using the obsolete name  |
|
| Back to top |
|
|
depontius
Advocate
Joined: 05 May 2004
Posts: 3522
|
| Posted: Thu Dec 25, 2014 12:43 pm Post subject: |
|
|
I don't recall ever seeing that message, and just checked - everything in my /etc/init.d uses runscript. In case this was a recent development, I just started updating this system, which was last updated last weekend. Still nothing of the sort here.
What's the story, here?
_________________
.sigs waste space and bandwidth |
|
| Back to top |
|
|
khayyam
Watchman
Joined: 07 Jun 2012
Posts: 6227
Location: Room 101
|
| Posted: Thu Dec 25, 2014 1:14 pm Post subject: |
|
|
| depontius wrote: | | What's the story, here? |
depontius ... seems to be bug 494220 ... quite honestly such a change simply to accomodate minicom seems to be imbalanced, particularly as now everyone migrating to openrc-0.13.x will recieve this warning and/or be required to migrate all of init.d/* to openrc-run. Added to that 'runscript' will still need to exist for compatibilty ...
best ... khay |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6780
|
| Posted: Thu Dec 25, 2014 2:07 pm Post subject: |
|
|
If filename collision can be avoided, it is always a good idea to do this: For this reason, I found the "generic" names runscript and rc rather unfortunate from the very beginning.
The migration seems to be done in a sane way: Now after a year since openrc-run is available, there are now starting warnings which do not hurt anybody, and I guess in yet another year or perhaps even later the old link will be dropped when hopefully everybody has paid attention to these warnings for his personal scripts and when all upstream-provided scripts are fixed. It is really not such a big deal to exchange one word by another for the advantage of avoiding collisions. |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Thu Dec 25, 2014 2:44 pm Post subject: |
|
|
| mv wrote: | | It is really not such a big deal to exchange one word by another for the advantage of avoiding collisions. |
It's dumb to inflict a debianism on Gentoo as a distro, imo.
We've been using /sbin/runscript for donkey's years; I don't see the point, at all. |
|
| Back to top |
|
|
Anon-E-moose
Watchman
Joined: 23 May 2008
Posts: 6148
Location: Dallas area
|
| Posted: Thu Dec 25, 2014 3:48 pm Post subject: |
|
|
It is dumb.
From github https://github.com/OpenRC/openrc/commit/3470eda3f5cea437a6de132b1ead3f27effd3902
| Quote: | Rename runscript to openrc-run
This was requested by Debian, because the minicom software, which is
available on Debian and other distros, has a binary named runscript. We
are keeping a backward compatibility symlink for now, but this allows
Debian or any other distro to safely remove the symlink. |
It is curious that debian is being named as the primary reason, when AFAIK debian wasn't on board to use openrc in the first place.
More than likely sysd want's to co-opt that name for it's own purposes, ala "debug" on the kernel command line. 
_________________
UM780, 6.1 zen kernel, gcc 13, profile 17.0 (custom bare multilib), openrc, wayland |
|
| Back to top |
|
|
depontius
Advocate
Joined: 05 May 2004
Posts: 3522
|
| Posted: Thu Dec 25, 2014 4:30 pm Post subject: |
|
|
Just a side-note. This is all ~arch stuff, and won't really hit stable until openrc-0.13.x. That's why the whole thread was a bit of a surprise to me, since I'm running openrc-0.12.4 at the moment.
_________________
.sigs waste space and bandwidth |
|
| Back to top |
|
|
Skippy204
Guru
Joined: 09 May 2008
Posts: 348
Location: Colorado, USA
|
| Posted: Thu Dec 25, 2014 4:34 pm Post subject: |
|
|
| depontius wrote: | I don't recall ever seeing that message, and just checked - everything in my /etc/init.d uses runscript. In case this was a recent development, I just started updating this system, which was last updated last weekend. Still nothing of the sort here.
What's the story, here? |
I've been seeing, and ignoring, this message for months. Six months at least. Maybe longer....
Or maybe it just feels like 6 months. Really can't say for sure 'cause the whole part where I just ignored it. 
Last edited by Skippy204 on Thu Dec 25, 2014 4:36 pm; edited 1 time in total |
|
| Back to top |
|
|
khayyam
Watchman
Joined: 07 Jun 2012
Posts: 6227
Location: Room 101
|
| Posted: Thu Dec 25, 2014 4:36 pm Post subject: |
|
|
| mv wrote: | | If filename collision can be avoided, it is always a good idea to do this: For this reason, I found the "generic" names runscript and rc rather unfortunate from the very beginning. |
mv ... fair enough, but given that this is the case why make the fix on the package that will have a disproportionate net effect? There are only two packages that have 'runscript' with one of them being in use in most systems and the other only a marginal case. It would seem far less disruptive to make the change in minicom, and/or work out some solution upstream. Also, we have had minicom in the tree for some time, surely this collision is a long standing problem, with both package using the same namespace, didn't someone notice that this name was in use prior to selecting it, and why is debian provided as the rational behind this when gentoo also has the same 'runscript' from mincom?
| mv wrote: | | The migration seems to be done in a sane way: Now after a year since openrc-run is available, there are now starting warnings which do not hurt anybody, and I guess in yet another year or perhaps even later the old link will be dropped when hopefully everybody has paid attention to these warnings for his personal scripts and when all upstream-provided scripts are fixed. It is really not such a big deal to exchange one word by another for the advantage of avoiding collisions. |
I'm more inclined to see this as an example of "future proofing" or what-have-you, more pain for very little gain. Its being migrated to take care of a corner case (something that, like "predictable network names" doesn't effect me or the great majority of users). While the warning is harmless there will no doubt be no end of posts, and so time wasted, on the subject, and until the symlink is actually removed the "problem" will persist.
Note that I don't have 'openrc-run', I'm using stable, so its not something that has been "available" for a year, it will no doubt appear out of the blue (again, like "predictable network names") and we will have a new round of "why am I getting this, what did I do wrong" etc, all for very little *real* benefit. So, no its not a "big deal", but taking into account the disruption, and weighing this against the paltry benefit, would seem to me far better than this need to "future proof" against corner cases.
best ... khay |
|
| Back to top |
|
|
Ant P.
Watchman
Joined: 18 Apr 2009
Posts: 6920
|
| Posted: Thu Dec 25, 2014 6:28 pm Post subject: |
|
|
| Maybe instead of accepting Debian's blind-idiot workaround of hiding the symptom (which they also inflict on useful tools like sys-apps/ack), we ought to be fixing the root problem, which is that dumping tens of thousands of files, named by as many different authors, into a flat /usr/bin and hoping there's no collisions simply doesn't scale. (and no, prefixing half of them with "g" or "k" is a cure worse than the disease...) |
|
| Back to top |
|
|
krinn
Watchman
Joined: 02 May 2003
Posts: 7470
|
| Posted: Fri Dec 26, 2014 9:34 am Post subject: |
|
|
It's never really bad to listen to users when you are upstream, so i think at least, that's a good point for openrc there.
But considering how debian just dismiss openrc (just to compare only upstart with systemd, just to make sure systemd would win the vote ; just the posix of openrc should had been enough to win it) and so only very few debian users should use openrc while the amount of gentoo users (and other non debian users) using openrc is big, it really looks odd the change was made.
There's a real problem, not specific to openrc, but gentoo: if "openrc" is a gentoo own project, and a critical one as it is default and not some random terminal but an init tool, then change to openrc that would affect gentoo users at least should be validate by some gentoo representative (dunno, Council?) and not leave on openrc maintainers hands.
It just mean if i'm maintainer of systemd, i could for no reason make it default today ; sure users will complain... but as-is i wouldn't break any gentoo rules as it seems none exists and everyone is free to just fuck the distro as he wish.
It doesn't mean of course none could reverse such a change, but it really mean that if someone do that, he should be safe as he doesn't break any rule ; no rules broken, no backfire... |
|
| Back to top |
|
|
Ant P.
Watchman
Joined: 18 Apr 2009
Posts: 6920
|
| Posted: Fri Dec 26, 2014 3:55 pm Post subject: |
|
|
| Also it's quite funny to note that openrc recently gained a "rc-service" -> "service" symlink... that name conflicts with something people might actually use - Upstart! |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Fri Dec 26, 2014 4:18 pm Post subject: |
|
|
| khayyam wrote: | | There are only two packages that have 'runscript' with one of them being in use in most systems and the other only a marginal case. It would seem far less disruptive to make the change in minicom. |
Exactly. After all this is about a distro, not someone's pet-project (which isn't even their work.)
| Quote: | | I'm more inclined to see this as an example of "future proofing" or what-have-you, more pain for very little gain. Its being migrated to take care of a corner case (something that, like "predictable network names" doesn't effect me or the great majority of users). While the warning is harmless there will no doubt be no end of posts, and so time wasted, on the subject, and until the symlink is actually removed the "problem" will persist. |
Yeah it does remind one of the udev "innovations"; change for the sake of it, ill-thought-through and deflecting focus from what really matters.
| Quote: | | Note that I don't have 'openrc-run', I'm using stable, so its not something that has been "available" for a year, it will no doubt appear out of the blue (again, like "predictable network names") and we will have a new round of "why am I getting this, what did I do wrong" etc, all for very little *real* benefit. So, no its not a "big deal", but taking into account the disruption, and weighing this against the paltry benefit, would seem to me far better than this need to "future proof" against corner cases. |
That is a big deal for me: it implies there's no-one thinking about the distro as a whole, much like with the gcc ABI changes.
While Gentoo may be from-source, and so require a bit more work on the part of the admin, the whole point of it is to be as painless as possible, given that we are building from-source. This is a change with no grounds, seemingly-designed to take up even more of our time for no reason. Though it does fit with an agenda of sucking up to anyone with a "name" rather than your users.
Frankly the changes since UberLord gave up maintainership, have mostly been cruft, apart from things contributed by users. Even where a patch was needed, they've been done really badly; resulting in embarrassing code or script.
| Ant P. wrote: | | Also it's quite funny to note that openrc recently gained a "rc-service" -> "service" symlink... that name conflicts with something people might actually use - Upstart! |
No no no ;) only systemd is something openrc-devs care about. ;p |
|
| Back to top |
|
|
Anon-E-moose
Watchman
Joined: 23 May 2008
Posts: 6148
Location: Dallas area
|
| Posted: Sat Jan 17, 2015 5:12 pm Post subject: |
|
|
| khayyam wrote: | | Note that I don't have 'openrc-run', I'm using stable, so its not something that has been "available" for a year, it will no doubt appear out of the blue (again, like "predictable network names") and we will have a new round of "why am I getting this, what did I do wrong" etc, all for very little *real* benefit. So, no its not a "big deal", but taking into account the disruption, and weighing this against the paltry benefit, would seem to me far better than this need to "future proof" against corner cases. |
openrc-13.7 went stable today (on amd64) I'm sure others will follow soon.
but even with the name change from runscript to openrc-run they haven't fixed any contention as they provide a runscript symlink
_________________
UM780, 6.1 zen kernel, gcc 13, profile 17.0 (custom bare multilib), openrc, wayland |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6780
|
| Posted: Sat Jan 17, 2015 5:29 pm Post subject: |
|
|
| Anon-E-moose wrote: | | as they provide a runscript symlink |
Of course, they do. They must do it until all ebuilds are updated eventually to provide inits with #!/sbin/openrc-run.
I for myself have already writen patches for all inits I use, and also all ebuilds I maintain in my overlays have already updated inits.
To my surprise not even netifrc (which I consider almost part of openrc) has not been updated yet and needed a patch... So it seems they are not hurrying with the transition. |
|
| Back to top |
|
|
khayyam
Watchman
Joined: 07 Jun 2012
Posts: 6227
Location: Room 101
|
| Posted: Sat Jan 17, 2015 5:32 pm Post subject: |
|
|
| Anon-E-moose wrote: | | openrc-13.7 went stable today (on amd64) I'm sure others will follow soon. |
anon ... and just as predicted the beginings of "why am I getting this, what did I do wrong" ... so we can waste our time supporting *stupid* changes like this.
| Anon-E-moose wrote: | | but even with the name change from runscript to openrc-run they haven't fixed any contention as they provide a runscript symlink :roll: |
Heres another eye roller ... minicom is a debian project, I guess it would have been too difficult to have them effect a name change.
best ... khay |
|
| Back to top |
|
|
khayyam
Watchman
Joined: 07 Jun 2012
Posts: 6227
Location: Room 101
|
| Posted: Sat Jan 17, 2015 5:44 pm Post subject: |
|
|
| mv wrote: | | Anon-E-moose wrote: | | as they provide a runscript symlink |
Of course, they do. They must do it until all ebuilds are updated eventually to provide inits with #!/sbin/openrc-run. |
mv ... ever had a conflict with mincom's runscript? Ever seen one reported on the forum, or elsewhere? Is it such a serious issue that a package used by a great majority of users *needs* to be changed to fix a corner case (which users never encounter)?
best ... khay |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6780
|
| Posted: Sat Jan 17, 2015 5:51 pm Post subject: |
|
|
This is an unfortunate bug which is already reported. This is a problem if core functionality is moved out of the package and apparently maintained by somebody else. We had a similar problem when some developer decided that it is a good idea that gcc-config should be an eselect module: Most people using this module ended up with a broken system, eventually. In a sense, we are lucky that it was only a trivial name change and not another internal interface change which could cause havoc with the eselect module. |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6780
|
| Posted: Sat Jan 17, 2015 5:57 pm Post subject: |
|
|
| khayyam wrote: | | Is it such a serious issue that a package used by a great majority of users *needs* to be changed to fix a corner case (which users never encounter)? |
The earlier the transition to a good naming scheme the better. I had this also with eix: There were the grown chaos name "eix-diff" "update-eix" "eix" etc. When doing the transition to names all starting with eix-*, it was a huge PITA: For the maintainer to provide compatiblity links/scripts (big hacks in the build system with scripts providing warnings etc.), for the users to fix their scripts etc. However, in the end, I think the improved names were eventually worth the hassle: You have one period of pain, but afterwards many years without any problems. And the earlier you do it, the less user scripts need a fixing. |
|
| Back to top |
|
|
khayyam
Watchman
Joined: 07 Jun 2012
Posts: 6227
Location: Room 101
|
| Posted: Sat Jan 17, 2015 9:01 pm Post subject: |
|
|
| mv wrote: | | However, in the end, I think the improved names were eventually worth the hassle: You have one period of pain, but afterwards many years without any problems. And the earlier you do it, the less user scripts need a fixing. |
mv ... I wouldn't say that the analogy is comparable (remember, there are no scores of people reporting issues with 'runscript', its a corner case at best), but ok, would you do the same again if minicom (or some other obscure package) had a script called 'eix'? Also, would you then say its "worth the pain" (also keeping in mind that that pain is not felt by you but by people supporting the entire distribution)?
| mv wrote: | | khayyam wrote: | | just as predicted the beginings of "why am I getting this, what did I do wrong" |
This is an unfortunate bug which is already reported. |
I would say its the outcome of [a] developers decisions ... the only thing unfortunate about it is that the developers involved will act as though that decision was correct ... regardless of the effects it will have on users and those supporting users.
best ... khay |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6780
|
| Posted: Sun Jan 18, 2015 5:56 am Post subject: |
|
|
| khayyam wrote: | | would you do the same again if minicom (or some other obscure package) had a script called 'eix'? |
If it would not be "eix" but a generic name like "info", I think I would do it again - independent of whether some other package already uses this name or not.
| Quote: | | I would say its the outcome of [a] developers decisions ... |
Yes, of decisions about the splitting but not so much about the renaming: Any interface change would cause the same trouble. Of course, the renaming is one interface change, but very likely not the only one which we will see over the years. (BTW: The code was not so optimal, anyway. For instance, scripts starting with #! /sbin/runscript (with a space) or #!/usr/bin/env runscript are not recognized, either. Not to speak about prefix) |
|
| Back to top |
|
|
khayyam
Watchman
Joined: 07 Jun 2012
Posts: 6227
Location: Room 101
|
| Posted: Sun Jan 18, 2015 9:06 am Post subject: |
|
|
| mv wrote: | | khayyam wrote: | | would you do the same again if minicom (or some other obscure package) had a script called 'eix'? |
If it would not be "eix" but a generic name like "info", I think I would do it again - independent of whether some other package already uses this name or not. |
mv ... so that's a no, you wouldn't.
| mv wrote: | | khayyam wrote: | | I would say its the outcome of [a] developers decisions ... |
Yes, of decisions about the splitting but not so much about the renaming: Any interface change would cause the same trouble. Of course, the renaming is one interface change, but very likely not the only one which we will see over the years. (BTW: The code was not so optimal, anyway. For instance, scripts starting with #! /sbin/runscript (with a space) or #!/usr/bin/env runscript are not recognized, either. Not to speak about prefix) |
The point here is that a major package was changed to fix a (supposed) issue with a minor package, in fact a package maintained by the same distribution asking for the change. This change will no doubt cause a heap of support issues, all for very little *real* benefit. We've already seen one issue with this change (two if we count the OP of this thread), on the very same day this change was released into stable, and will no doubt see more ... yet net-dialup/minicom has been in the tree for ages, and there are no users having reported issues (that I know of) during this timeframe. So, its not an issue of some "needed" change, but the outcome of those changes measured against the scale of the problem.
best ... khay |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6780
|
| Posted: Sun Jan 18, 2015 9:45 am Post subject: |
|
|
| khayyam wrote: | | mv ... so that's a no, you wouldn't. |
"rc" and "runscript" are rather generic names, in contrast to "eix". Not as generic as "info", but on the border. Now a known collision was probably the final straw to do the fixing now, and I would probably have done the same if I would have been the developer.
Edit: English ("final straw"). I hope this phrase is now correct. |
|
| Back to top |
|
|
khayyam
Watchman
Joined: 07 Jun 2012
Posts: 6227
Location: Room 101
|
| Posted: Sun Jan 18, 2015 10:32 am Post subject: |
|
|
| mv wrote: | | khayyam wrote: | | mv ... so that's a no, you wouldn't. |
"rc" and "runscript" are rather generic names, in contrast to "eix". Not as generic as "info", but on the border. Now a known collision was probably the final straw to do the fixing now, and I would probably have done the same if I would have been the developer. |
mv ... yes, but we use generic names all the time: "bridge", "shutdown", "runuser", etc, etc, and, as far as I know, there is no other use of "runscript" other than minicom. The point being that this collision was a corner case and if anything should be changed it would be far less disruptive to make that change at the point where the least disruption might be felt.
Now, I assume that this argument could be made for other scripts, so if some obscure package out there has a /usr/bin/bridge, or /usr/bin/runuser we should change iproute2 and util-linux so that these "generic" names don't conflict.
| mv wrote: | | Edit: English ("final straw"). I hope this phrase is now correct. |
Ummm ... yes, its a correct turn of phrase, but really its not suitable in the above, a "final straw" (or, "the straw that broke the camels back") is really only used when "many straws" have already made the load heavy ... so, lots, and lots, of prior instances causing the "final straw" to break the camels back.
best ... khay |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Other Things Gentoo
