View Single Post
Old 11-18-2011, 03:08 PM   #83
NiLuJe
BLAM!
NiLuJe ought to be getting tired of karma fortunes by now.NiLuJe ought to be getting tired of karma fortunes by now.NiLuJe ought to be getting tired of karma fortunes by now.NiLuJe ought to be getting tired of karma fortunes by now.NiLuJe ought to be getting tired of karma fortunes by now.NiLuJe ought to be getting tired of karma fortunes by now.NiLuJe ought to be getting tired of karma fortunes by now.NiLuJe ought to be getting tired of karma fortunes by now.NiLuJe ought to be getting tired of karma fortunes by now.NiLuJe ought to be getting tired of karma fortunes by now.NiLuJe ought to be getting tired of karma fortunes by now.
 
NiLuJe's Avatar
 
Posts: 4,596
Karma: 4440239
Join Date: Jun 2010
Location: Paris, France
Device: Kindle 2i, 3g, 4, 5w, PW & PW2
I'm all in favor of a proper FS hierarchy for hacks .

In fact, I've been mostly following a loose scheme for my packages (/$hackname/{bin,etc,lib,run,$data}), minus the prefix (but that sure would help with the mess in the us root ^^), and avoiding messing with the rootfs in install scripts (usually just an init script and the runlevels symlinks), and keeping a human readable versioning info (both for the release package itself via $hackname/info.txt, and for every non binary file with the SVN $Id$ keyword). And, like salfred said, it doesn't take much effort to do that manually. A fully fledged PMS seems a little overkill to me .

As for the install process itself (or a launcher), keep in mind that some hacks (ie. usbnetwork) have very specific timing requirements regarding when they can be started during the boot process.

I actually like the update process as an installer (it's already there, users usually know about it, it's nicely integrated in the system, it handles runlevels switching for us (ie. some hacks might need the framework to be down/other hacks stopped to be installed correctly)), but I'm not against something custom, provided it has a simple GUI/visible user output, and detailed logging/debugging capabilities.

EDIT: But I also like the idea of no per-package install scripts at all, and just one 'package manager' setup during the jailbreak install, and a simple file/folder to drop/delete to install/remove stuff. It's not convenient for packages that *need* to touch the rootfs someway beyond a simple init script during the install process (because they'd have to do it another time, and probably mntroot rw to do so), and it could be tricky to handle the timing of when to start stuff during the boot process, and we would then *really* need a launcher/installer, because for now the update process takes care of everything for us.

Last edited by NiLuJe; 11-18-2011 at 03:19 PM.
NiLuJe is offline   Reply With Quote