Joined: Sep. 2005
||Posted: Sep. 20 2006,18:27
One reason I posted this simple convenience is I know people enjoy using little tools (especially with ANSI colors, or pop-up boxes, I know I do). Rows of command line stuff is intimidating to newbies, so I'm hoping this will get people making some more uncs. I made 6 uncs effortlessly within minutes of finishing this. Psychologically, deb2dsl is more satisfying because the user has to type things into boxes (ie participates more => more ownership). Probably should add a few boxes ;=)
|with contributions such as dsl2unc|
Uncs are great, a huge improvment on dsls (thanks to Robert). Ucis will probably (?) remain the "queen" of extensions - they don't require unionfs and they don't put anything irreversibly on the system filesystem.
But some things will never be ucis alone. An example is gnupg. I built a gnupg.uci that works (haven't got round to sending it to the repo). However, some applications that use gnupg-encrypted keys (an example is aespipe, another is loop-aes) expect to find gpg in one and only one place: /usr/bin/gpg. Whether or not gpg is in PATH anyway is irrelevant to these apps. I suspect there are other similar examples about. So there will remain a technical need to have gnupg.dsl or a gnupg.unc in addition to gnupg.uci. (You could run a wrapper to set up the symlink gpg -> /usr/bin/gpg, but this means running /etc/init.d/mkwriteable. Actually, the loop-aes author says you must physically *move* the gpg binary to /bin and then do a symlink /bin/gpg -> /usr/bin/gpg - who am I to argue with someone like Jari Russu?)
|if using "-type -f" might limit or even break some extensions. If an extension includes one or more symlinks, or even an empty directory|
Good point. Without that -type f, will get clobbering directories like /opt/bin passed into the unc (clang!). There's ways around that. I wrote an unrelated script (buried on my hd somewhere) with some bash that removed clobberers - I'll dig it up.