dotpups, pupgets, directories, package managers...

Stuff that has yet to be sorted into a category.
Message
Author
GuestToo
Puppy Master
Posts: 4083
Joined: Wed 04 May 2005, 18:11

dotpups, pupgets, directories, package managers...

#1 Post by GuestToo »

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

improving 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
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 fine

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

dotpup/pupget integration stuff
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 clicked

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
What about internationalization?
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 likes
package management in Puppy
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 packages

The 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
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-only

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)

User avatar
jmarsden
Posts: 265
Joined: Sat 31 Dec 2005, 22:18
Location: California, USA

#2 Post by jmarsden »

when i thought up the dotpup idea, Puppy's /usr was read-only ... files would usually be installed in my-applications/ ...
So in the past, installing stuff under root may have been appropriate. Good point.

In the light of BarryK having made a specific request to install things into /usr/local, and in view of the FHS -- can we expect those who have released dotpups to issue updated packages that follow the now-current approach?
... you are assuming that pupget is bug free and always works properly
Running any dotpup is assuming that the dotpup is bug free and always works properly too -- any dotpup could contain a dotpup.sh that deletes or modifies any file anywhere on the entire system! There is no real extra "safety" in installing in /root rather than /usr/local given the overall Puppy approach in which almost everything runs as root. If you really need to keep your filesystem safe, make regular backups :-)
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
OK

Code: Select all

function pupget-register () {
  # Append package entry to alien package list if not already there
  grep -s "^\"$1\" " /root/.packages/alienpackages.list ||
    echo "\"$1\" \"$1: no description available\" on \"UNKNOWN"}\" \\\\" >>/root/.packages/alienpackages.txt
  # Create package list
  cat "$2" >>/root/.packages/"$1".list
}
Stick that in a file, source it in your dotpup.sh and call it just as you suggested. Job done :-) NOTE THIS IS UNTESTED AND UNSUPPORTED CODE WRITTEN ON THE FLY -- DO NOT USE ON PRODUCTION MACHINES YET! It lacks the ability to provide a description, or the extra group and size info that pupget would like in its catalog, but it strictly follows your function definition.
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 ...
I'm pretty sure there is a fairly authoritative web page at http://www.pupweb.org/puppy/development ... gement.htm
(written by BarryK I think) describing both forms of Puppy packages, and it seems to me to state that closer integration between the two approaches is being thought about or worked on... but maybe I am just misunderstanding it?
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 ...
Frankly, this sounds a bit like fingerpointing between two development teams that should be cooperating. But anyway, if neither team is willing to take responsibility for the little bit of glue code necessary to interface the two packaging systems better, no problem, I'll provide it, maybe a few people will find it handy. See above for a first attempt at creating a function that you seem it be suggesting could usefully be added.
What about internationalization?
... dotpup packages are very flexible ... the packager can pretty much do what (s)he likes[/quote]Yes, which means that, for a good end user experience using the whole system and its apps, appropriate conventions and guidelines are going to be required. It sounds like you are saying that no-one has yet thought about this very much?
the dotpup was not intended to be a package manager
Well, it is in effect being used as one, since it installs packages on Puppy systems! So like it or not, it seems to have become one of the two available package management tools in wide use on the Puppy distro.
... in fact, i suspect that some people really should be making Unleashed packages, not dotpups)
Perhaps so, but there is no clear guidance on this on the Puppyweb sites that I have seen so far, and also the "unleashed" approach seems to currently require direct involvement of BarryK to get packages published, which is a potential bottleneck since he is the primary OS developer :-) I'd rather let him spend his time on the core OS than on vetting lots of packages from the package developer community, personally.

Jonathan

User avatar
Pizzasgood
Posts: 6183
Joined: Wed 04 May 2005, 20:28
Location: Knoxville, TN, USA

#3 Post by Pizzasgood »

the dotpup was not intended to be a package manager
Well, it is in effect being used as one, since it installs packages on Puppy systems!
Actually, that makes it an installer. It doesn't do any managing, which as I see it also includes keeping track of the packages and removing them.

I was actually the first person to take advantage of having a dotpup register with pupget to allow it to be removed. I think I did that maybe two more times, then I ceased. I realized that I prefered roxapps much more. They're easier to keep up with. In the last Pizzapup, I actually put Firefox within a roxapp. That turned out to be a problem, though, because it was in /root/, which made the image.gz file huge. Oh well. Live and learn, I guess.

As for unleashed packages, that only has to go through Barry for it to be in the official repository, and thus show up in Pupget. You can still install them as alien packages, and remove them normally. You could probably even assign them a special file extension and set them to auto-install.

Personally, though, I'd prefer dotpups to not register unless they install all over the place. I definately don't want the actuall dotpup process altered. Maybe make a separate utility to keep track of and remove them that the individual dotpup creator can choose to use. Because some stuff wouldn't be suited for it, and for other stuff it would be a waste of time.

As for combining them, I think that should be avoided. A separate dotpup manager is fine, but they should probably not mess with the pupget stuff. That would make it easier for both systems. Besides, why take the middle ground when you can have both ends? Use dotpup for what it's good for (quick, easy installs), and use unleashed packages for what they're good for (dealing with packages with many spread out files). No sporks for me please. I'd rather use a spoon for soup and a fork for pork.


But those are just my opinions. I can carve my own utensils from scratch if neccisary. More likely though, I'd just be lazy and deal with the sporks. :wink:
[size=75]Between depriving a man of one hour from his life and depriving him of his life there exists only a difference of degree. --Muad'Dib[/size]
[img]http://www.browserloadofcoolness.com/sig.png[/img]

User avatar
jmarsden
Posts: 265
Joined: Sat 31 Dec 2005, 22:18
Location: California, USA

#4 Post by jmarsden »

Lobster wrote:the dotpup was not intended to be a package manager
jmarsden wrote:Well, it is in effect being used as one, since it installs packages on Puppy systems!
Pizzasgood wrote:Actually, that makes it an installer. It doesn't do any managing, which as I see it also includes keeping track of the packages and removing them.
The most definitive information I can see for Puppy package developers is the web page at http://www.pupweb.org/puppy/development ... gement.htm which I linked to earlier. It says, in part
BarryK wrote:Anyway, with the release of version 1.0.1, /usr became writable, by use of a technique known as unionfs. Suddenly the gates were opened, and along with two new package managers, PupGet and DotPup, we have had a flood of new packages.
I'd say that makes calling DotPup a package manager not all that unreasonable.
Pizzasgood wrote:As for unleashed packages, that only has to go through Barry for it to be in the official repository, and thus show up in Pupget
Which is pretty much the definition of an unleashed package, isn't it? :-) See http://www.pupweb.org/puppy/puppy-unleashed.htm for how the term is used there. A Pupget package is one in the form used by Pupget. An Unleashed package is a Pupget package which is in the Unleashed repository. Well, that's how I use the words, and how BarryK seems to on his web pages -- do you have a better or more official source for definitions of these terms, that I should be using instead? I'm just a newcomer, I might be using them wrongly. If so, please help me learn to use them correctly, by pointing me at their definitions. Thanks!
Personally, though, I'd prefer dotpups to not register unless they install all over the place. I definately don't want the actuall dotpup process altered.
As I think this dialog is already demonstrating with some example ideas and even code, what we might be talking about is a "recommendation" or "guideline" that dotpup.sh files include a couple of lines to register themselves and the files they install. Two lines. Maybe

Code: Select all

. /usr/local/bin/pupgetfuncs.sh
pupget-register "joe-3.3" "Joe's Own Editor"
is a reasonable example. Is that too much to ask of developers? Two lines in a shell script, to add substantial order and management capability to one's computing environment, making it easier for users to find out "what packages did I install?" and "what version of package X is installed?" as well as making it possible to uninstall dotpup-installed software in the absence of the original package file.

Have you spent a few months using a Puppy system that has, say a couple of hundred dotpup-installed apps on it, and tried to keep your versions of those apps updated, etc.? OK. Now imagine doing that over a couple of hundred Puppy-based workstations in an office... then to an organization with a few hundred offices worldwide... it would be quite a difficult task :-)
Maybe make a separate utility to keep track of and remove them that the individual dotpup creator can choose to use.
Utility? We're talking about a few simple shell functions, at most, here. I see no need for anything as large as a new application, at this stage.
Because some stuff wouldn't be suited for it, and for other stuff it would be a waste of time.
??? It's "a waste of time" for developers to add two lines to each dotpup.sh they create, so that their users can actually keep track of what they have installed? I think the tradeoff of a couple of lines of shell script for keeping potentially thousands of workstations manageable, is one that is definitely worth making! Think long term, and assume Puppy will continue to be popular, and expand into new kinds of uses for new classes of users ... and then try to explain how and why "it would be a waste of time" for you to write two simple lines of shell script, compared to wasting hundreds of hours of user and sysadmin time as they fight to keep thousands of workstations updated and reliable.

Overall I think you grossly underestimate the value of package management in the longer term, on all but purely "hobbyist" systems with "throwaway" filesystems containing no information of significant value. Puppy is capable of being useful for more than that. A lot more. But it may well require a small amount of developer and packager discipline to get there.

Jonathan

GuestToo
Puppy Master
Posts: 4083
Joined: Wed 04 May 2005, 18:11

#5 Post by GuestToo »

The most definitive information I can see for Puppy package developers is the web page at ... /usr became writable, by use of a technique known as unionfs. Suddenly the gates were opened, and along with two new package managers, PupGet and DotPup, we have had a flood of new packages.
whatever it says on that page, the dotpup system obviously has no package management tools or functions built into it

the dotpup handler is a simple shell script, basically 3 lines:

unzip
md5sum check
exec dotpup.sh

that's all it is ... that is all it was ever intended to be ... it certainly is not a package manager ... it was never intended to be a package manager (it can make use of any external package management tools that might be provided, of course)

it was intended to be an installer like NSIS
http://nsis.sourceforge.net/
but simpler and minimalistic ... NSIS uses scripts to configure the installer program's behaviour ... dotpups use a shell script called dotpup.sh which is more powerful and flexible than an NSIS script anyway ... of course, dotpups are not limited to shell scripts ... they can use puppybasic or tcl/tk or even compiled executables

it implies on that web page that the dotpup system did not exist before unionfs made /usr writable ... that is not true ... i remember when /usr became writable, and i remember wondering whether i should make my dotpup packages install in /usr or my-applications ... i remember that what i did for a while was to install in /usr if it was writable and install in my-applications if /usr was read-only ... older versions of puppy were still being used and /usr was not writable in these older versions

in fact, the first dotpup package i uploaded (a tcl/tk freecell game, found by atang1) was uploaded before pupget existed, and before Unleashed existed and before /usr was writable ... i did not call them dotpups then, and they unzipped to my-applications/, and the script that executed was named pupinstall.sh, not dotpup.sh

if you read further down the package management page, it says
DotPup is a simple package installation system developed by GuestToo
this is correct ... DotPup is a simple package installation system

it also says
Another nifty thing about Mark's DotPup package installer is that it registers the package with the PupGet package manager
this is not true ... it does not register anything with pupget

it also says
Under the hood, we are working toward these two systems to be cooperative
i don't know who "we" is referring to, but it do not think it refers to me ... when Puppy upgrades, it cheerfully deletes any files that were installed in /usr ... this makes it awkward to install to /usr ... then Barry set up a file registration system so that files that were registered were left alone ... i find it as easy or easier to just avoid installing in /usr ... then Barry created the PCCC script which creates an iso from what you have installed ... it adds files that are registered with pupget to the iso ... files in /usr are added to usr_cram.fs and files in /root are added to image.gz ... so if you want to register packages with pupget, it's better to install the files in /usr than to /root, in the interests of keeping image.gz small ... i have made no dotpup packages that would make image.gz larger if PCCC was run

there seems to be no references to greater "integration" between dotpups and pupget on that page ... there is one reference to "cooperation", but i think that just refers to the fact that dotpup packages can register files with pupget ... i think this is all that is meant by "integration" ... i see no point in making the dotpup system more like pupget
jmarsden wrote:
Well, it is in effect being used as one, since it installs packages on Puppy systems!
a package installer is not necessarily a package management system ... in this case, the dotpup system is certainly not a package management system ... and was never intended to be a package management system
I'd say that makes calling DotPup a package manager not all that unreasonable.
DotPup should never have been referred to as a package manager in the first place ... loose terminology is not really important considering the group of people the dotpup system is targeted at ... people who have problems with concepts like unzip, tar, chmod, permissions ... but for package developers, loose terminology might be a little confusing
a "recommendation" or "guideline" that dotpup.sh files include a couple of lines to register themselves and the files they install
i think it's important to understand what is behind the recomendations ... files installed in /usr will be removed when Puppy upgrades ... files that are in /root will be added to image.gz when PCCC is run

if you have a large program installed in /root, maybe Java or Xampp or Open Office, you probably do not want them being put in image.gz when you run PCCC ... you might, or might not, be happy with them going in usr_cram.fs

most of my dotpup packages install in /root and do not register with pupget ... they would be ignored by PCCC so they would not make image.gz larger

the dotpup system is a simple installer, not a package management system ... i don't think it needs to have package management tools built into it ... i think making package management tools and functions available to it is useful and practical

GuestToo
Puppy Master
Posts: 4083
Joined: Wed 04 May 2005, 18:11

#6 Post by GuestToo »

What about internationalization? ... It sounds like you are saying that no-one has yet thought about this very much?
i used to leave out the language files ... for one thing, Puppy did not support other languages and fonts at all ... recently, that has been changing, and Puppy is more capable of handling locales and fonts ... i often include the language files now, but i'm not sure that they are useable ... as i said, i have been making decisions on a package-by-package basis ... no one has published any rules or guidelines, to my knowledge
In the light of BarryK having made a specific request to install things into /usr/local, and in view of the FHS -- can we expect those who have released dotpups to issue updated packages that follow the now-current approach?
i believe that request was referring to the PCCC iso creator ... the history is this:

at first, /usr was read-only

then, /usr was writable

then, files installed in /usr would be removed when Puppy upgrades

then, files that registered with pupget were left alone

then, PCCC would add registered files to the iso

files in /root would be added to image.gz, and files in /usr would be added to usr_cram.fs, so if you have files registered with pupget, it would be better to put them in /usr than in /root

most of my packages will be ignored by PCCC so they will not make image.gz larger
Running any dotpup is assuming that the dotpup is bug free and always works properly too
the dotpup system pretty much is bug free ... not because i am a brilliant programmer, but because it is deliberately simple and minimalistic ... basically just a 3 line shell script ... dotpup packages and the programs in the packages are not necessarily bug free, of course

i do not like manipulating the pupget data files directly ... it is not good programming practice ... there is no interface to pupget to register packages, so that pupget can be treated as a black box ... that interface should be part of the pupget system ... it should not be part of the dotpup system, or built into Gaim or Firefox or wget or any other program

i do not like incorporating a pupget registration routine or subroutine in the dotpup.sh script ... i think it should be an external tool ... as far as i'm concerned, it belongs to the pupget system

and by the way, Busybox's ash and bash treat script functions differently and use a slightly different syntax
Frankly, this sounds a bit like fingerpointing between two development teams that should be cooperating. But anyway, if neither team is willing to take responsibility for the little bit of glue code necessary to interface the two packaging systems better, no problem, I'll provide it, maybe a few people will find it handy
i believe that in this case, good programming practice would be to use the object oriented programming model of the black box ... pupget registration should treat pupget as a black box, and should not need to manipulate pupget's data files directly ... i think pupget should have a simple registration interface ... i have been reluctant to write an interface myself, because i am not familiar with the pupget program amd how it works ... i registered 1 file with it once, and found it didn't work properly because pupget considered the filename to be too close to an Unleashed package already in the list (Rox 1.2 vs. Rox 2.3) ... also, i don't think it worked anyway ... i seem to have registered it according to the instructions, it appears in the installed packages list, the filelist for the package is in the data folder ... but the file that i registered seems to have been removed anyway when i upgraded to Puppy 1.0.7

User avatar
Pizzasgood
Posts: 6183
Joined: Wed 04 May 2005, 20:28
Location: Knoxville, TN, USA

#7 Post by Pizzasgood »

Which is pretty much the definition of an unleashed package, isn't it? Smile See http://www.pupweb.org/puppy/puppy-unleashed.htm for how the term is used there. A Pupget package is one in the form used by Pupget. An Unleashed package is a Pupget package which is in the Unleashed repository. Well, that's how I use the words, and how BarryK seems to on his web pages -- do you have a better or more official source for definitions of these terms, that I should be using instead? I'm just a newcomer, I might be using them wrongly. If so, please help me learn to use them correctly, by pointing me at their definitions. Thanks!
Sorry, I tend to use Pupget package and Unleashed package interchangeably (well, actually I tend to just use Unleashed package for everything). Probably due to the fact that nobody has really made any. I think I remember some months and months ago, but nothing since then. Sorry for the confusion.
Because some stuff wouldn't be suited for it, and for other stuff it would be a waste of time.
??? It's "a waste of time" for developers to add two lines to each dotpup.sh they create, so that their users can actually keep track of what they have installed?
Sorry, I should clarify.
I definately don't want the actuall dotpup process altered.
I meant the actual dotpup handler, not the dotpup.sh within each dotpup. This stuff should be on a dotpup to dotpup basis.
Because some stuff wouldn't be suited for it, and for other stuff it would be a waste of time.
First off, I meant not all dotpups need to or even should register. Sometimes they are a simple alteration of a file, or a small test script, or some other thing. Another thing to keep in mind about dotpup is that it isn't just an installation script. It can do anything that a script can do, such as modifying files and downloading bigger files (many do that). Simply registering what they come with wouldn't be sufficient to undo file modifications, and it would miss the downloaded files. So uninstalling would get tricky, and sending that info to Pupget would be even trickier. Plus, you have to take into account that something else might alter those files. Then we run into "Windows Add/Remove Programs" syndrom. If I accidentally delete the files, they mess up the uninstaller and I have to screw with the registery to fix it, possibly screwing up everything else. (Not that I would, but someone else might)

Basically, what I'm getting at is that for normal software additions, dotpup should be abandoned for pupget. Use a spoon for soup. Now, when you want to test small scripts or mess with less "hairy" stuff, use the fork.

Everyone's always going "Combine dotpup and Pupget." Why? Pupget can already do the job. If it lacks something, add it yourself and show Barry. What are the main advantages to using dotpup instead? There are dotpup makers, and the one-click install. This can be done with Pupget too, you just need to make the stuff to do it. Actually, from what I understand, Pupget packages are supposed to be easier than Dotpup to make (by hand).

The main reason dotpup has gotten so big and pupget ignored is probably just that it came first and is just what people started using. So when Pupget came around, everyone wanted dotpup to be more like Pupget, instead of using Pupget itself.
i believe that in this case, good programming practice would be to use the object oriented programming model of the black box ... pupget registration should treat pupget as a black box, and should not need to manipulate pupget's data files directly ... i think pupget should have a simple registration interface ... i have been reluctant to write an interface myself, because i am not familiar with the pupget program amd how it works ... i registered 1 file with it once, and found it didn't work properly because pupget considered the filename to be too close to an Unleashed package already in the list (Rox 1.2 vs. Rox 2.3) ... also, i don't think it worked anyway ... i seem to have registered it according to the instructions, it appears in the installed packages list, the filelist for the package is in the data folder ... but the file that i registered seems to have been removed anyway when i upgraded to Puppy 1.0.7
Ditto. And yes, Pupget is confusing. But if I managed to survive keeping track of the code within when I hacked it up to make PupBeGone, I'm sure other people can too. I suggest reading up on grep and sed first so you can keep track of what's going on. And bring a pencil and paper. I made the mistake of just using my memory, and got lost pretty quickly. It can be modified though. It's just another (hairy) script. In fact, a good starting point would be to clean it up a bit and make it more function based. It could be named something else so as not to mess up the real deal, and eventually become much more powerful. When you want a better spoon, upgrade a spoon, not a fork.
[size=75]Between depriving a man of one hour from his life and depriving him of his life there exists only a difference of degree. --Muad'Dib[/size]
[img]http://www.browserloadofcoolness.com/sig.png[/img]

GuestToo
Puppy Master
Posts: 4083
Joined: Wed 04 May 2005, 18:11

#8 Post by GuestToo »

not all dotpups need to or even should register
i agree with that

for example, Puppy 1.0.7 comes with mtPaint 2.10
since 1.0.7, mtPaint 2.20 has been made available, and i made a 2.20 dotpup package

this package does not register with pupget, so if you upgrade Puppy, then Puppy will remove mtPaint 2.20

if my mtPaint 2.20 package registered with pupget, then mtPaint 2.20 would be retained if Puppy upgraded

if the newer Puppy came with mtPaint 2.10, you might appreciate keeping the newer mtPaint ... if the newer Puppy came with mtPaint 2.20, it wouldn't make any difference ... if the newer Puppy came with mtPaint 2.30, it will be replaced by the older mtPaint 2.20 that was installed by the dotpup package

there are similar situations with system files and library files ... a package that registers with pupget might prevent you from having the latest version of a particular file

in particular, i do not register any of the files in my unofficial SP packages ... most of the bugfixes in the service pack will probably be fixed in the newer version of Puppy anyway ... if they aren't, a new service pack can address the specific bugs in the newer version of Puppy
Another thing to keep in mind about dotpup is that it isn't just an installation script
i agree with that also

dotpup packages are usually installers, but they don't have to be ... it's a very simple and flexible system ... the dotpup package is just an executable and optionally some zipped files

for example, a dotpup package could be a program, for example, a game that unzips itself and runs when you click it, and is deleted when you finish playing the game ... as opposed to installing
Use a spoon for soup
i think dotpup and puget have differences ... i don't see any point in making the dotpup system more like pupget ... or apt-get or urmpi or any other paclkage manager ... it really wasn't intended to be a package manager like apt-get and synaptic ... the dotpup system was intended to be a simple (minimalistic) installer, aimed at new Puppy users who are used to using Windows ... it was intended to be flexible, with the installer program built into the package as opposed to packages that have a single external installer program, which is more rigid
The main reason dotpup has gotten so big and pupget ignored is probably just that it came first
i suspect this is not true

i uploaded my first dotpup package before Unleashed existed, or pupget existed, or /usr was writeable ... but the dotpup system was not implemented in Puppy at that time ... it was implemented at the same time that pupget was, that is, they were both introduced in the same version of Puppy at the same time (though i had made a dotpup-system installer before that, which required unzipping and chmod'ing skills ... but for all practical purposes, dotpups and pupget were introduced at the same time)

some differences between dotpup and pupget
1) the interface (the Unleashed gui was originally intended to be used by advanced users ... dotpups were intended to be used by newbies)
2) the exact packages that are available
3) dotpups can be uploaded anywhere by anyone, anytime ... pupget/Unleashed packages have to be uploaded to the Unleashed repositry by Barry

User avatar
jmarsden
Posts: 265
Joined: Sat 31 Dec 2005, 22:18
Location: California, USA

#9 Post by jmarsden »

Note: This is a long post, even for me!
Pizzasgood wrote:Sorry, I tend to use Pupget package and Unleashed package interchangeably ...
(well, actually I tend to just use Unleashed package for everything). Probably due to the fact that nobody has really made any. ...
OK. However, someone has made some, or there wouldn't be

Code: Select all

19:53:41 root@jm:~/.packages# wc -l /root/.packages/unleashedpackages.txt
    348 /root/.packages/unleashedpackages.txt
19:54:00 root@jm:~/.packages#
348 entries in that file :-) All of these are pupget packages (they conform to the pupget spec), which are also Unleashed packages (they are in the Unleashed repository)! Who created them? I don't know, because (sadly) Pupget packages do not yet store author and packager information in them, the way more mature packaging formats do. But that's a discussion for later. The point for now is that there are 348 such files as of today, so it seems that "nobody has really made any" is incorrect, or at best only partially correct?

Perhaps you intended to say something more like "recently, no-one seems to have made any new pupget packages that are not in the Unleashed repository"?
First off, I meant not all dotpups need to or even should register. Sometimes they are a simple alteration of a file, or a small test script, or some other thing.
Sure, if you write a dotpup for a couple of friends to use and email it to them, and your small group of friends all knows what is going on and are all just running hobbyist Puppy systems. But in the general case, dotpups that are published as being suitable for general consumption by Puppy users, do need some form of adequate package management. IMO. I'm seeing things like Java and OOo published as dotpups -- those are hardly just test scripts!
Another thing to keep in mind about dotpup is that it isn't just an installation script. It can do anything that a script can do, such as modifying files and downloading bigger files (many do that). Simply registering what they come with wouldn't be sufficient to undo file modifications, and it would miss the downloaded files.
So the dotpup.sh concerned needs to be a bit smarter about which files it registers. Not a huge deal.
So uninstalling would get tricky, and sending that info to Pupget would be even trickier. Plus, you have to take into account that something else might alter those files.
Now you understand why designing a truly useful package management approach is not all that simple. Now you begin to see the value of RPM %postuninstall scripts, files labeleld as ghost, missingok, config, -- this is a system that tries hard to address many of the issues you raise, and mostly succeeds. As does .deb for that matter.
Then we run into "Windows Add/Remove Programs" syndrom. If I accidentally delete the files, they mess up the uninstaller and I have to screw with the registery to fix it, possibly screwing up everything else.
Even PupGet handles this, unless someone accidentally messes with its database (~root/.packages/*).
Basically, what I'm getting at is that for normal software additions, dotpup should be abandoned for pupget.
Fine with me :-) But where is this recommendation on the Puppy Developer web pages? I don't see it. I'm new. I'm learning by reading the most official docs I can find for Puppy developers, and reading the forums, and starting to get involved. And it's not at all clear that dotpup's are basically just a quick hack that is totally unsuitable for "normal software" (your words) and so "should be abandoned" (your words again) for such use.
Pupget can already do the job. If it lacks something, add it yourself and show Barry.
So, you are saying here that the model for proposing changes to the Pupget package management spec requires *implementing* those changes, before even discussing them and reaching consensus within the developer community on what enhancements would be useful? Wow, that's a high barrier to entry -- it means that those with ideas for enhancements have to design and implement and test their ideas before getting any feedback from the rest of the development community? Is that really how coperative development is supposed to work in the Puppy community?!

I have ideas about pupget adding author, packager, package creation date/time, install date/time, and allowing signing by packagers and maybe reviewers (so we can verify that packages are legitimate and and have not been tampered with). Those few enhancements would be a good start. Longer term, I have questions about the reasoning behind it's using a unique and somewhat unwieldy text file format for its databases. Why wasn't something already well defined, such as CSV for example, used in those files? Could pupget v2 or v3 transition to CSV or some other existing file format? Or even to a 'real' database format such as Berkeley db files or similar??

Now, I'd prefer to proceed roughly like this: discuss those ideas, get feedback, modify them in the light of feedback, write up a preliminary revised package spec, and a design doc for the primary package management tool that would use packages that conform to that spec, have the key developers in the Puppy comunity (once I know who they are, and including BarryK of course) approve the spec, and only then actually set about implementing that spec. But you seem to be stating very clearly that this is not the way development work is supposed to be done around here! Please confirm. The idea of having to do all the design/implement/test work solo, with zero input or feedback, and then to just release the "new improved" packaging approach and tool(s) and lib(s) on Barry and on an unsuspecting developer community which ahs had no input into the enhancements, is pretty unappealing to me, frankly. It's not the way most open source development communties work, and seems highly inefficient.
What are the main advantages to using dotpup instead? There are dotpup makers, and the one-click install. This can be done with Pupget too, you just need to make the stuff to do it.
Sure, those are not hard. Maybe I should abandon dpupmaker.sh and go for a pupgetmaker.sh instead? Sure, I can do that, but I'd like some sort of consensus from the key players in the Puppy development community that such a tool would actually be useful, and would be used if it existed, before I write and test it... but that means I need to figure out who those key players (other than BarryK) really are!

Actually, the real barrier to wider pupget package adoption, as far as I can see, is that getting your packages released under dotpup more or less requires that they go through BarryK. There are Wiki pages where I can add (say) a dozen dotpup's tonight. Pages that people looking for additional software for Puppy know to go look at. Pages some package management tools go look at, even. I can't do that for pupget packages!
Pupget is confusing. But if I managed to survive keeping track of the code within when I hacked it up to make PupBeGone, I'm sure other people can too.
In my opinion, that's a poor approach to take. A package management system needs a clearly defined specification. Developers should use that spec. to create tools and packages. They may also use some kind of specification conformance test tool (such as rpmlint for RPM creators). They do not generally expect to have to read the source code for other peoples tools, and reverse engineer some hopefully correct idea of the spec from that -- that is so inefficient and such a waste of developer time that it borders on criminal. There is a PupGet specification on the web, or what pases for one, titled Technical details of PupGet , at http://pupweb.org/puppy/development/pac ... gement.htm . Given who its author is (BarryK), I think it can be assumed to be reasonably authoritative (please correct me if I am wrong about this!). Therefore, if a new pupget package management tool B conforms to that published specification, but still somehow breaks some other pupget-related tool A, then this means that:
  • there is a newer and clearer official spec somewhere which the developer of tool B should have used, or
  • the official spec is ambiguous and needs revision, or
  • the tool that is non-conformant and so must be fixed is A, not B
[regarding PupBeGone] It's just another (hairy) script. In fact, a good starting point would be to clean it up a bit and make it more function based.
There are very few developers who would relish the job of cleaning up someone elses "hairy" code. No thanks. I agree a function library for pupget package management is a very good idea. I'm surprised one doesn't already exist. But if I create one, it will be based on the published pupget specification, not on any one pupget tool's code!!

THE BIG QUESTION: If I were to decide to take on the creation of a shell (probably bash) function library for pupget package management as an actual project, would you (and would others in the Puppy developer community) be willing to:
  • provide appropriate input and feedback,
  • read and comment on a draft specification,
  • help me get BarryK's stamp of approval on the spec (I have no idea how to go about doing that!), and then
  • help to test (perhaps somewhat broken) test versions of the resulting library and
  • report bugs, and
  • suggest enhancements, etc.?
Jonathan

User avatar
jmarsden
Posts: 265
Joined: Sat 31 Dec 2005, 22:18
Location: California, USA

#10 Post by jmarsden »

GuestToo wrote:whatever it says on that page, the dotpup system obviously has no package management tools or functions built into it
True. So, either the Puppy developer community needs to create guidelines and standards and helper scripts and function libraries and so forth that help dotpup in that area, or it needs to openly admit that dotpup is thoroughly unsuitable for installing applications, if the resulting systems are to have any chance of remaining maintainable for the longer term.

The current situation, where dotpups that install major applications without any apparent form of package management are published on Puppy-related web pages and forums for general Puppy-user use, is essentially anarchic and is (in my view) completely unsustainable. If it continues, the Puppy community will (again, in my view) be digging itself into a deep hole of tech support and upgrade issues, which will be rather difficult to climb back out of.

Pizzasgood seems to be suggesting just giving up on dotpup and using PupGet. If you, as the creator of the dotpup package format, basically continue to believe something like "Flexibility is what matters. dotpup isn't supposed to deal with managing the applications it installs at all." (my paraphrase), then Pizzasgood's suggestion is 100% correct. In that case, the dotpup package format clearly should be relegated to the trivial hobbyist stuff only. ASAP.

Instead of dismissing the dotpup format as too simplistic to be useful, I have been trying to provide some help for dotpup as an approach, to make it easier and simpler for dotpup creators to allow the applications they package (as dotpups) to be suitably managed.

My first attempt at this was a script (dpupmaker.sh) to ease compiling apps from tarballs, turning them into dotpups which register themselves with Puppy's package database. BarryK indicated his congratulations, suggesting I was on a reasonable track with that idea. However, so far not a single Puppy packager or developer has yet used it to sucessfully create a dotpup and reported their success to me, either publically or privately. So I may have created a tool that no-one wants to use, or that no-one is able to use... or I may just be impatient!

Further, if you,as the creator of the dotpup package format, are actively opposed to package management related enhancements for dotpups, OK, fine. I have no desire to battle with you over this, it is your package format. I'll just drop dotpups and move on :(
the dotpup handler is a simple shell script, basically 3 lines
Agreed and understood. There is probably no need to change that script. I have never suggested changing it, as far as I know! [[ Well, obviously, adding a little basic error-checking would be wise, so that the end user is suitably informed when the unzip fails, or when the md5sum's mismatch, or when the dotpup.sh exits with an error status... but that's not something I have been looking at or thinking about until right now! ]]

There is an apparent need to create guidelines and standards for dotpup creators who want to use the dotpup package format to install applications (a common current use of the dotpup file format, I hope you will agree). Further, I suggest that there is an apparent need to create software tools to help such package developers follow the relevant guidelines and standards, so they can be more productive. That's what I've been trying to do so far.

It sounds as though you, as the creator of the dotpup installer/file format, are basically saying "I do not want this sort of enhancement of my vision". OK, I'll respect your wishes.

I would suggest that you might find it valuable to work with Barry to get his web pages for Puppy developers corrected, since I (wrongly?) thought they were intended to be authoritative, yet you seem to know of many flaws in them which somehow have not been corrected. For the sake of other newcomers to the Puppy developer and packager community, I would urge you to do whatever it takes to get these inaccuracies corrected. Soon.
DotPup should never have been referred to as a package manager in the first place ... loose terminology is not really important considering the group of people the dotpup system is targeted at
The page which calls it one is targetted directly at developers, for whom precision of language is often critical.
the dotpup system is a simple installer, not a package management system ... i don't think it needs to have package management tools built into it ... i think making package management tools and functions available to it is useful and practical
Making things "available to it" is a waste of developer time (my time, if I am the developer concerned!), unless the people who create dotpups will actually use them. My impression at this point is that you and some others basically want dotpup creation to always be super-simple, and so don't really want to be bothered to understand and work with package management. I don't blame you for that (about seven years ago, I developed short courses and taught classes on how to create RPMs and their .spec files. I know first hand that there is a lot of detail involved in defining and correctly using a fully-fledged package management system!). It seems I picked the wrong package file format to work with within the Puppy community. Long term, Puppy will, apparently, need to use a different file format than dotpup for packaging applications. My sincere apologies for any difficulties my making a poor initial choice has caused.

Honestly, it's a bit discouraging to be a developer and sysadmin who is newcomer to Puppy, trying to help move a commonly-used Puppy-specific package format along a bit, so it can be more useful for the long haul, and to be getting feedback that basically says "you are doing the wrong thing, this isn't what this package file format is supposed to be used for, and isn't a direction it should be taken in". OK. I've heard. I understand. Not a huge problem, I've only been here a week! I'll work with the pupget file format instead. Let's see how that goes.

Jonathan

User avatar
Pizzasgood
Posts: 6183
Joined: Wed 04 May 2005, 20:28
Location: Knoxville, TN, USA

#11 Post by Pizzasgood »

Okay, we had a little more miscommunication.
When I said "If it lacks something, add it yourself and show Barry," I didn't mean you should just go and do it. I meant more like, "Hey, Pupget should do this and this. What do you guys think? Okay, cool," then work togeather and if it turns out good, let Barry know and he might include it in the next release. By do it yourself, I meant "take it into your own hands since nobody else is doing it," not work solo.

I also didn't mean for anyone to mess with PupBeGone. I wouldn't tell my worst enemy to look inside that monstrosity. No, I was referring to PupGet. I meant that if my (at the time) sleep-deprived mind could understand PupGet (while I made PupBeGone from it), than it is possible for other people to comprehend PupGet. Especially if they already know how to use grep and sed, and sketch the program flow out on paper. The hairy code was also reffering to PupGet. PupBeGone is way past hairy. I should have done it from scratch like I originally intended. :roll: And it's not so much that the code is hairy, it just gets confusing keeping track of what the for loops within while loops messing with grep conditions that my mind kept flip-flopping are doing.

As for taking someone's code (though I know you were talking about PupBeGone), the only ways to upgrade something are to edit it's code or start from scratch. So to beef up Pupget, you would have to either study it's code and improve it, or start over.
Fine with me Smile But where is this recommendation on the Puppy Developer web pages? I don't see it. I'm new. I'm learning by reading the most official docs I can find for Puppy developers, and reading the forums, and starting to get involved. And it's not at all clear that dotpup's are basically just a quick hack that is totally unsuitable for "normal software" (your words) and so "should be abandoned" (your words again) for such use.
Yeah, there are some out of date pages. I haven't really looked at them in a while. I tend to just stick to the forum and the two news pages. The wiki is probably the best place to look for info, because it can be edited easier, so it should stay up to date better. I think.
As for the dotpups, I haven't really thought about "abandoning" them until this discussion. It's kind of like a windows installer versus a self-extracting zipfile. But where the installer is a pain in the but to use. I think that if pupget was set up to let you click on, say, a .get file, ask permission and then install, it would be much more useable. Right now, you can click a dotpup, but you have to run pupget and click "install alien package," then find the package before it installs. I think I'll leave the ideas about this to you, though, because you obviously have more experience than I do in the area of package managers. I do agree that the textfile might not be the best way, and one of the reasons pupget is so slow is that it sorts through and recreates the file several times.

One problem with using Pupget rather than Dotpup is that the problem of Puppy keeping registered files remains. I don't know how Barry is doing the upgrading process on Puppy2, but if it is different, then it might not matter. Otherwise it might need upgrading too, in order to work efficiently. I usually just start over fresh, and have only upgraded by accident, so I don't think about that problem often. Maybe if it checked the version of the packages and prompted the user about replacing them.

As far as your dotpup maker goes, personally I use G2's template that he made a long time ago. I just like doing it myself more than having a script do it for me.
[size=75]Between depriving a man of one hour from his life and depriving him of his life there exists only a difference of degree. --Muad'Dib[/size]
[img]http://www.browserloadofcoolness.com/sig.png[/img]

User avatar
Nathan F
Posts: 1764
Joined: Wed 08 Jun 2005, 14:45
Location: Wadsworth, OH (occasionally home)
Contact:

#12 Post by Nathan F »

I used to be in the camp that wanted to make all dotpups behave like packages. I wanted them to register with Pupget every time. I have completely changed my mind on this approach after I started making unleashed packages.

If anyone thinks that there are no recent unleashed packages available I'd like to point out the Grafpup package repository. Although some of the programs I've put in it need a little tweakinb in order to run in Puppy, the fact remains that I've made or altered around 50 unleashed packages for Grafpup in the last three months.

The unleashed format is indeed quite a bit easier to implement than a dotpup. You don't even need an install script in most cases. Pupget handles almost everything itself and does an excellent job of it. In fact, I really don't think it needs much in the way of the kind of improvements that have been mentioned here. There are a few things that should be improved about it, but the package format itself is just fine. I do see the point in adding developer information and that may be a good idea. I also think that documentation could be better on how to make one.

The thing that has made unleashed packages kind of inaccessible up until now is that the only person who actually has access to the repository is BarryK. No one else can upload to it, and Pupget does not get an updated package list until you upgrade to the next release. Dotpups, on the other hand, can be uploaded by anyone and new ones appear all of the time. With all due respect to BarryK, he has not always been very quick to add anything I've made to the repository either.

In the long run, here are the things that I think should be done with package management in Puppy. Many people are making dotpups out of large and complex pieces of software that install all over the Puppy filesystem. This practice is not good, for the reasons stated above. I have no objections to dotpups in general, but they are best suited as roxapps like G2 has said over and over again. Most of the developers should switch to making unleashed packages, however. I think Pupget does need an additional capability added so that it can update the list of available packages, either every time it connects to the archive or just when you tell it to do so. I actually had a dotpup that updated the list when I was halfway through the last release cycle of Grafpup, but I'd rather have the Pupget script do it itself. I also think that the repository should be opened up to allow a slelct group of other users to add packages to it. There could be a testing directory also, full of testing packages which the brave could download and install as alien packages. Some of these changes will eventually have to be made as Barry slowly transfers the whole project over to the Puppy foundation anyway.

Dotpups ARE a good thing and should be available. They are not well suited for everything, however. I still make them occasionally, however. For Grafpup I have a whole array of Gimp extensions available that install inside /root, most of which are very small scripts or plugins. I have made all of these into dotpup packages. A dotpup is also an easy way to update a configuration or do a bugfix like G2's service packs. There is also the capacity to use the directory /my-aplications for many programs and the they won't be removed by Pupget. I made a dotpup out of the Bomberclone game that I compiled by passing --prefix=/root/my-applications to ./configure. This is a good compromise but still leaves one with the problem of not having a way to track what is installed on your system. You could also compile a program with the prefix /root/my-roxapps/name-of-package in order to make the creation of a roxapp easier. Then you would just have to turn it into an appdirectory and add an APPRUN script. In this way the package can be removed by just deleting the directory. You could also symlink to the executable in /my-applications/bin and this would allow you to run it from the command line. This is an even better compromise in many cases. I really don't think it's a good idea to have a a lot of dotpups that install into /usr right now the way things stand, however.

A lot of the things I've mentioned are things that I've thought of implementing in Grafpup but I'm kind of reluctent to make any changes in the way Pupget works. I'm trying to keep the packages compatible with Puppy and Grafpup whenever possible so changing Pupget itself might defeat that. The other thing is that even though I'm concentrating my effort on Grafpup I'm still a big fan of Puppy and I'm trying to make sure my efforts can trickle down into Puppy. That won't happen if I let things get too incompatible, and it would be just like the situation with Debian and Debian based distros that have so much trouble with packaging, or all of the distros that use rpm and all have to have seperate repositories. But I guess this is off topic a little.

jmarsden, I was very interested in your script by the way. I haven't used it because I abandoned making dotpups that install into /usr quite a while back. It would be a neat idea to have an automated script to build an unleashed package, however. Or you could just alter the script to allow the user to choose the prefix they want to compile for. Either one would be very useful to me and I'd be a lot more likely to use it. But anyway, I for one think it was a great idea in the first place.

GuestToo
Puppy Master
Posts: 4083
Joined: Wed 04 May 2005, 18:11

#13 Post by GuestToo »

i'm not nearly as familiar with pupget as i am with dotpups, but i think Unleashed/pupget packages can be installed as alien packages, so they can be uploaded to any server, and people can download them and install them using pupget

Unleashed packages are tar.gz's and some servers are not configured properly for gz files (the servers treats them as text files) ... which is why i used zip to package dotpups ... it's probably possible to put Unleashed packages in dotpup packages and have them install using pupget automatically ... giving pupget packages the advantages of the dotpup system (automatic one-click install, md5sum checking, download from any server) ... a simple program could be written to wrap an Unleashed package in a dotpup

GuestToo
Puppy Master
Posts: 4083
Joined: Wed 04 May 2005, 18:11

#14 Post by GuestToo »

the only ways to upgrade something are to edit it's code or start from scratch
this is an interesting point

i deliberately chose to have the program that does the work in the dotpup package rather than have it in the Puppy system, like pupget

this makes dotpups very flexible and powerful (and dangerous too, unfortunately)

it also means that the dotpup system is very extensible and upgradable without having to change the dotpup handler at all ... if you want to add package management tools and functions, you just have to provide a few executables for the dotpup script to use (and they would not have to be built into Puppy either, they could be included in the dotpup package ... though i would prefer that the tools were built into the Puppy system)

if you want to upgrade or extend pupget, you would have to change the pupget executables

GuestToo
Puppy Master
Posts: 4083
Joined: Wed 04 May 2005, 18:11

#15 Post by GuestToo »

As for the dotpups, I haven't really thought about "abandoning" them until this discussion
dotpups were intended to work like Windows install-me.exe files ... this makes them simple and easy to use and familar to Linux newbies that are used Windows (click to download - click to install)

but install-me.exe files are potentially dangerous, and dotpups are too, for the same reason ... i knew this when i created the system ... dotpups do make Puppy less safe than it would have been ... maybe this is reason enough to consider whether to keep the system in Puppy

i personally think that dotpups are very useful ... the question is ... are they a little too useful for safety?

GuestToo
Puppy Master
Posts: 4083
Joined: Wed 04 May 2005, 18:11

#16 Post by GuestToo »

I think that if pupget was set up to let you click on, say, a .get file, ask permission and then install, it would be much more useable. Right now, you can click a dotpup, but you have to run pupget and click "install alien package," then find the package before it installs
dotpups were intended to be really easy to use ... just click to install ... this was the primary idea i had when i thought of them, and i think the way i did it works quite well

the pupget interface came from the Unleashed interface, which was intended to be used by advanced users to build their own Puppy iso's

GuestToo
Puppy Master
Posts: 4083
Joined: Wed 04 May 2005, 18:11

#17 Post by GuestToo »

personally I use G2's template
i just use a package i made recently as a template when i make a dotpup package

usually, it's either a simple package which just needs a few minor changes to my make-tar script and my dotpup.sh file (which is usually only 2 or 3 lines anyway) ... or it's a complicted downloader/installer which an automatic dotpup maker (like MU's) could not build anyway

GuestToo
Puppy Master
Posts: 4083
Joined: Wed 04 May 2005, 18:11

#18 Post by GuestToo »

if the resulting systems are to have any chance of remaining maintainable for the longer term.
i don't think of Puppy as an enterprise solution, with hudreds of Puppy os's running on hundreds of (possibly thin-client) machines ... my Morizot-based firewall assumed that Puppy was a stand-alone desktop (i provided tools to make more complicated firewalls) ... my dotpup packages more-or-less assume that Puppy is basically a stand-alone desktop too

the dotpup system is definitely not a complex package management system like apt-get or urpmi ... if someone choses to make package management tools that it can use, it might be a good idea to have guidelines and organization for creating the package management system ... the dotpup installer is too simple to need more than a Hints And Tips page or two ... like NSIS, it is a simple installer tool ... i don't think organizations that use the NSIS installer need guidelines that recommend how they should and should not make their packages

http://nsis.sourceforge.net/Users
# Winamp (audio player)
# SHOUTcast server, plug-ins (music streaming system)
# Google (Gmail, Picasa 2, Google Talk, Video)
# ATi (just as a wrapper)
# DivX (video codec)
# Kaspersky (antivirus)
# Intel C Compiler (free evaluation version)
# City of Heroes (commercial MMORPG game)
# Sun Java Web Start
# UC Berkeley (computer security CD for campus residents)
etc etc etc

there are people who actually like bureaucracy ... they like to attend meetings ... i don't ... and there's always the danger of being eaten by the mutant star goat

GuestToo
Puppy Master
Posts: 4083
Joined: Wed 04 May 2005, 18:11

#19 Post by GuestToo »

Slackware does not have a package manager as such, and doesn't seem to need one ... i've installed slapt-get, ... other than installing 2 or 3 packages just to try it out, i have never used it or needed it

this is not to say i am opposed to having packages or package management tools in Puppy, or to say that Puppy needs or does not need a package manager ... i was just pointing out that there are distro's that do not have a package manager

GuestToo
Puppy Master
Posts: 4083
Joined: Wed 04 May 2005, 18:11

#20 Post by GuestToo »

So I may have created a tool that no-one wants to use, or that no-one is able to use... or I may just be impatient!
you are probably impatient ... it was a long time before anyone but me made a dotpup package

Post Reply