Some init script ideas

tehdely · 2004-03-04 20:55:45

I'm packaging GNUstep... again (this time from CVS), and it requires a certain shell script to be sourced by every shell. That's easy enough for any user to do by modifying their .foorc and adding it in there, but I thought I would just throw a command in the postinstall to symlink the shell script to /etc/profile.d, so every login shell would automatically source it.

That's all fine and dandy, but xterms by default aren't login shells, so anybody using an xterm would find themselves without a working GNUstep build environment unless they set xterm to be a login shell in their .Xdefaults.

Change #1) Make xterms login shells by default in Arch's xfree86 distribution

Now that xterms are all login shells, and we can expect a user's shell to be a login shell by default, why not add scripts to profile.d for the various self-contained distributions that live in /opt (like gnome, kde, java, etc.) that automatically set up the paths for those binaries. At the moment, it appears you have to do this manually (I have not installed gnome or kde though, maybe those maintainers are doing this).

Change #2) Have packages that live in /opt add a script to profile.d setting up the paths and environment necessary to use those packages.

Thirdly, there's two daemons that need to be started for GNUstep when xfree86 starts (specifically gdnc and gpbs). Once again, this is something that can easily be done by a user editing their .Xsession, but I'd rather automate it. In the spirit of Arch's init script system, I think it would be wise to make an xinit.d directory (possibly in /etc, or more to the keeping of X's directory structure, in /etc/xinit.d), full of files that are run whenever X is started. These could be enabled and disabled in rc.conf just like init scripts in rc.d currently are.

Change #3) Add an xinit.d directory, in the spirit of rc.d and profile.d, full of items that are run whenever X is started.

Perhaps some of this has already been done, or perhaps there are other solutions. I just think these changes would be well in the spirit of Arch, and a boon to package maintainers.

Please give me your feedback either here or by mailing me at usemike@spamblocked.com

-- Michael Baehr

sarah31 · 2004-03-04 21:01:16

most if not all /opt package sets have profile.d scripts. some may not think so but one has to log out then in to enable them.

Xentac · 2004-03-04 21:08:24

Ok... but what happens if I'm running blackbox? I probably don't want gdnc and gpbs started when I start X, it'd make me cry. How would xinit.d help with that?

tehdely · 2004-03-04 21:58:02

sarah31 wrote:

most if not all /opt package sets have profile.d scripts. some may not think so but one has to log out then in to enable them.

Good Looks like profile.d is being used for the right purpose. I should've expected it would be :oops:

Xentac wrote:

Ok... but what happens if I'm running blackbox? I probably don't want gdnc and gpbs started when I start X, it'd make me cry. How would xinit.d help with that?

I don't see why it'd make you cry. Let me explain what gdnc and gpbs are:

GNUstep Distributed Notification Center
Handles messaging and notification between GNUstep applications
GNUstep Pasteboard Server
Handles rich copy and paste between GNUstep applications

Basically, none of these would impact whatever environment you'd be running, and only GNUstep apps would use them. In fact, you wouldn't even realize they were running as they'd just be sitting in the background like the valiant daemons they are, waiting to be called into service for the holy emperor GNUstep :twisted:

And in any case, with the whole xinit.d idea, you should be able to just disable it with a ! if you don't like it

I might as well throw in my last idea, which I forgot to write before.

I've noticed people complaining about Pacman upgrades wiping their pacman.conf, which is a problem if you're using several people's TURs and other external repositories like I am. Instead, I propose doing what APT has been doing in a recent version with its new sources.list.d layout... having one directory (pacman.repo.d or something of its ilk) storing files for each repository, and enabling and disabling them in pacman.conf the way you do in rc.conf (with a bang). This would be especially nice because somebody could install a package called, for example, "pacman-TUR", and have a repo file for each TUR, and then be able to enable or disable them. This package would be updated every time a new TUR was added or one was removed, thus enabling people to easily track the latest repository happenings, while still maintaining control over what repos they use.

Just a thought.

sarah31 · 2004-03-04 22:13:18

to the latter point ... rather than get that complex why not just have all turs listed in the default pacman.conf?

to the xinit.d well if you create an xinit.d you have to create more code to enable it in the init scripts and accomodate for it in rc.conf. it maight be easier to have an rc.d script that you can put in rc.conf that acts like a self contained xinit.d directory. or just a wrapper script to start the two daemons you mentioned.

Xentac · 2004-03-05 01:05:16

I prefer not to run anything unless I need to. I don't need to run those daemons, why should I? In archlinux just about everything is opt-in. You have to say you want it. Nothing is started without your permission.

I don't understand how a ! can stop files from being run. Just like everything in /etc//profile.d it would be run without discretion. It's not like you have a list of xinitrc services you'd want run in some file. It just stupidly goes through each file and runs them.

What about killing them? If I was someone who started X only to check out some webpages, but really used the command line a lot, then I'd have these daemons running that would never be used, regardless of whether or not I used gnustep.

skparkes · 2004-03-05 13:23:57

I personally agree. I don't want extra daemons running. That is a very nice part of arch, there's very little goin by default.

Now, speaking of "xinit.d" or something like that, since rc.conf seems to be a great place to house stuff, maybe we could put a small section in there for changing the default runlevel. I know it just involves editing one oher file, but that's true for most of rc.conf.

Later,

Isamoor

Arch Linux

#1 2004-03-04 20:55:45

Some init script ideas

#2 2004-03-04 21:01:16

Re: Some init script ideas

#3 2004-03-04 21:08:24

Re: Some init script ideas

#4 2004-03-04 21:58:02

Re: Some init script ideas

#5 2004-03-04 22:13:18

Re: Some init script ideas

#6 2004-03-05 01:05:16

Re: Some init script ideas

#7 2004-03-05 13:23:57

Re: Some init script ideas

Board footer