when i thought up the dotpup idea, Puppy's /usr was read-only ... files would usually be installed in my-applications/ ... now /usr is writable, but Puppy might delete files from /usr at any time, espacially when Puppy upgrades to a new version ... you can "register" with pupget (ask it to leave your files alone), but you are assuming that pupget is bug free and always works properly
i think the dotpup system is more-or-less complete ... it was never intended to be a package manager or to have package management tools built into the system ... but having easy access to package management tools is fineimproving the productivity of package creators with simple tools and scripts, much less on generic ways to ensure dotpups register themselves as alien packages with PupGet
in particular, i think there should be a simple interface to pupget registration, as opposed to directly editing the files in /root/.packages ... it's possible to accidently damage the pupget configuration so that it won't run ... something like
pupget-register mypackage-0.0.1 filelist.txt
i'm not particularly interested in integrating the dotpup system with the pupget system ... if you want to make dotpups more like Unleashed packages, it would probably be better to just use Unleashed packages ... pupget is a repository system in which the pupget program controls what the package does ... dotpup packages are more flexible - the package controls what happens when it's clickeddotpup/pupget integration stuff
the lack of an registration interface to the pupget system is not a lack of integration between dotpups and the pupget system ... it is a question of the pupget system being incomplete ... sometimes object oriented programming is a good idea
Rox 2.3's package is about 600k and the language files are about 600k so i made a seperate language package ... mtPaint 2.20's language files are not very big, so i included them in the package ... dotpup packages are very flexible ... the packager can pretty much do what (s)he likesWhat about internationalization?
again, the dotpup was not intended to be a package manager ... it was intended to be very simple (minimalistlic) ... mostly to be very easy to use and newbie-friendly ... but providing easy access to package management tools for dotpup scripts is a good thing because it makes it easier to create packagespackage management in Puppy
for earlier versions of Puppy, the only writable dir was /root (pup008) ... user spot did not exist ... i created user spot to run some programs as an unprivledged user ... /root was the only place to put files and dirs ... there could have been a dir /home, maybe symlinked to a dir in /root, but it would have to be symlinked or mkdir'ed every time Puppy booted ... /root/spot was simpler ... i was not the Puppy developer so i was not in a position to add /home to the Puppy file system ... as i said before, for a long time, Puppy's /usr was read-onlyThe spot user has a home dir of /root/spot, for one egregious example in Puppy itself. And some (older?) dotpups seem to want to put things under /root also.
Putting additional (locally installed) software under /usr/local fits with the FHS, so I'll do it that way until someone who knows Puppy better than I do explains why it is a bad idea
my Sunclock package, for example, has all of the files in a dir called Sunclock ... help files, binaries, library files, config files ... it's a Rox application directory, so it's supposed to work that way ... to uninstall the package, you can just delete the dir ... i compiled it to install in the standard locations in /usr, and set it up so when it runs it installs symlinks in /usr to the files in the appdir ... because Puppy's /usr is a dangerous place to put anything, i set it up so that it reinstalls the symlinks every time Sunclock is run ... rather like a virus ... i did not register anything with pupget (for one thing, i got used to avoiding /usr before pupget allowed registration ... for another, i intended it to be a package that installs to the hard drive after Puppy is already installed ... registering with pupget is mostly necessary if you intend some sort of remastering ... if i wanted the package to be included in a remastered iso, i would probably just move the appdir to /usr/local/apps and make an Unleashed package ... in fact, i suspect that some people really should be making Unleashed packages, not dotpups)