prototype dotpet instaler

[Nathan F]

There was a while back quite a lot of buzz here on the forum about the idea of creating a dotpet package format. The format would basically be the same as unleashed, but add the capability to click a package in ROX and have it install (among other proposed enhancements). There was a lot of enthusiasm for it right from the start but it seemed that not much was really happening.

I've managed to get a system up and running on my computer that does just that, which I could use a bit of extra input on. I'll post the guts of it here sometime soon but right now I'm just going to describe what the pieces are and what they do. I'm not a very capable programmer and didn't feel like reinventing the wheel so much of what I did has been hacked right out of Pupget itself, so I'd like to credit Barry for much of it.

What the system is is a collection of three scripts (currently). There are two file handlers and one package installer. I want to make it clear that nowhere have I said anything about having written a package manager. That task would still be handled by Pupget, at least until something better or faster comes along. The package installer basically replicates the actual installation step in Pupget, but can be called seperately from the command line or another script and takes as an argument the name of the package you wish to install. The first handler basically just downloads a package and places it into /root/.packages, then it gives you the option to install it by calling the installer script, view the package information (which isn't yet implemented but has been discussed on the forum. It would have to be decided what way was best to implement meta info into the package.), or abort. The second handler is activated when you click on a package in ROX, and it gives the same three options.

The reason I created it as three seperate scripts is for flexibility and easier debugging. For instance the downloader could be called from a dotpup's installation script to resolve a missing dependency, similarly from a dotpet's pinstall.sh. This adds the possibility to do some basic dependency tracking and resolution which is becoming a little more of an issue than it was previously. It also allows for simpler and faster operation. Since you don't have to wait for the script to parse all of the package lists before it starts package installation is almost as fast as if you were installing a dotpup. I've also left out the dependcheck function which speeds it up further (it can still be run from Pupget later if there seems to be a problem with the program). I'm sure the whole thing could be incorporated into one monolithic script much like Pupget but I really felt this way was better, and definately more UNIX-like in it's approach.

There are still a few issues that need addressed before it could be used. For instance currently a package must be on the livepackages.txt list in order for the script to register it properly. I'm going to try adding a function that will ad an entry to alienpackages.txt if a suitable entry isn't found in the other lists, but it hasn't been implemented yet. If anything related to a dotpet format is ever to be adopted then we as a community should develop a standard for the format if we wish to extend it in any way (ie the addition of metadata such as the name of the packager, creation date, etc.). I favor doing so in an XML file inside the top level directory of the package. It could then be fairly easily read by the handler scripts (by extracting just that file and parsing the data) or by a web server, which could use the info to generate a page with package descriptions. These are just possiblilities and could be implemented later, but a standard should be agreed on if anyone wants to proceed.

Also, if anyone thinks there might be a better wat to implement the idea please go right ahead and develop it. I'm sure that many of you are a lot more capable of doing it well than I am. Just please keep me in the loop if you do.

Nathan

[Pizzasgood]

I'm sure the whole thing could be incorporated into one monolithic script much like Pupget but I really felt this way was better, and definately more UNIX-like in it's approach.

I like it your way. Like that, you can have custom front ends for it. Other programs can utilize it too. Much more flexible.

[jmarsden]

Nathan, I think we need to cooperate... I have a mostly-working .pet installer too... built from scratch rather than from pupget code, and missing some safety features and checks that would need to be in one intended for public use... and some other minor things that need fixup... but it does basically install stuff from at least some .pets when they are clicked on, for me anyway

I don't mind whether we end up with multiple scripts doing separate jobs or one larger multifunction script, as long as the code is clear and well commented, and the core of what is being done is cleanly separated from the UI.

I think a library of functions that this set of scripts uses is a good way to avoid duplicating code between them. It also makes for easier code-reuse when someone comes up with ideas for a variation they want to try out -- they can use (some of) the function library but not the primary scripts and their UI, for example.

I have a few too many things going on to promise to work to a set timetable, but do you have a particular need to get a .pet installer made public by a certain date? It's been maybe 5 weeks since .pet was first discussed in earnest... is that really so awfully slow that you felt you needed to go solo to get this done in time for your needs?

As for the distinction between "installer" and "manager", there is surely a blurred line between them? If an "installer" checks whether you already installed a package and prevents you from installing it twice, is that "management"? Or if it warns you about dependencies and refuses to install a package until they are met, is that "management"? What about if it offers to install the missing dependencies for you first, and then install the package you asked to install? If it goes out to the Internet and downloads them for you in order to do that? At what point has the "installer" become a "manager"? I think this may turn out to be an unhelpful and rather impractical distinction to make.

Jonathan

[Nathan F]

Jonathan-

Really I didn't mean to come away sounding impatient on the issue, and if I intended to go solo I wouldn't have written the last paragraph in my first post. It sounds like you have indeed been working on it and it would be nice to see what you've come up with at some point. As for a timetable go ahead and go at your own pace, I'm not in a drastic hurry here and would rather see the 'right' system put in place than something hacked together without too much thought. I did intend to put a limited test of certain concepts into Grafpup-103 but that's probably at least two or three months off.

More important than the speed at which something gets implemented is that there is some consensus on what features we want to have that aren't available now, and that we can come to an agreement as a community as to the best way to implement certain things. My impression from the previous discussion is that the most requested feature of a revamped package management system for Puppy is click to install, followed by better package description and categorization, and definately a speedup over the way Pupget functions now. I really think dependency resolution would also be achievable without a whole lot more effort as well.

I like the sound of what you said about a function library, and it's actually somwhat similar in approach to the way I have my system set up now. It would be interesting to see just how you have split up the various functions.

I guess you're right in saying that the line between 'installer' and 'manager' is not helpful to draw. I just wanted to point out that the scripts I've pieced together aren't a full package management system but just certain elements that would make up the whole. What I have so far only handles installation and registration of the package and files. It doesn't handle uninstalling, clash checking, dependencies, etc.

In any event a lot of things will have to change for Puppy2 anyhow, so I wasn't going to try and get anything adopted right now. I just wanted to see what ideas and interest there might be and that's why I posted what I did.

Nathan