Hardcore Puppy Meeting

[Lobster]

We had a very productive meeting

Notable highlights (as I remember it)
Dex was asked to produce his bookmark.html
Trobin is busy writing *A History of Puppy - the early years" -
Still much debate over package management
Babbs is creating new depository of files
and Mark will have one functional in about a month
New "Puppy manual" started
http://puppylinux.org/wikka/ManualBeginners
Raffy could not get through
More winks required and announced, more tutorials on wiki required
Pizzapup went camping (or creating Empty crust
J-Rey pointed great links such as http://puppylinux.org/docs/
Ian went to have breakfast

What do you remember . . .


Read it for yourself here thanks to Jmarsden

transcript of the meeting
http://puppylinux.org/wikka/Foundation006Transcript

[Pizzasgood]

Whoops! Sorry 'bout that, I wasn't camping (maybe on the 27-29'th though), I just forgot about the meeting
I spent most of yesterday (10:30-17:00 or so) working on Empty Crust. Then I had to let my brother on the computer for the rest of the night.

As for Empty Crust, it's down to 40 MB, but it's about to go up a smidgen because I apparently removed something I shouldn't. I'll ask about that in another thread later (I need to write down the error message). My main goal for today is only to fix that problem. The rest of the day I need to spend finishing some college applications and getting my hair cut. I have no school tomorrow, though, so I'll tear back into it then. I think it's nearly complete, though. Most of the weight worth removing is now gone. What's left is mostly questionable in whether I should remove it, and wouldn't make much difference size-wise.

As far as PizzaPup goes, it depends on stuff. I'm extra busy this semester (senior year and all), so it won't be in the very near future. Depending on how soon 1.0.8 comes out, it might wait 'til then. I need to finish Empty Crust and Personal Pan first. Then I don't know what I'll be doing. Depends on what I learn with Personal Pan. If I get loaded up on all kinds of ideas, I might make PizzaPup right away. Otherwise, I might put it off for a bit and work on some other projects. Possibly, I'll work on some other non-Puppy projects that I've been neglecting (finishing PHnotsoPlacid, for example).

I read the transcript, and agree about the .pget stuff. I kept seeing stuff about enhancing dotpup, but instead of making big changes to dotpup, just make little changes to Pupget and achieve the same effect. Which is what jmarsden was saying if I remember right. It would be a good idea to set standards for both methods, though, such as readme's and uninstall scripts (for those pesky dotpups that shouldn't be regestered for whatever reason).

If I had an income, I'd donate some money. But I don't. Like I said in another post, I've spent only $40 since last August. In fact, I have maybe $12 left in my wallet and $4 in coins spread throughout my room. I have more in the bank, but that's for college and a laptop. I might send in a small portion of my summer wages in August, though.

Well, Mom's yelling about that haircut, so I'd better get going.

[Nathan F]

I just read the transcript and it was a very productive meating. Sorry I haven't attended very many, but they always seem to occur while I'm at work.

I'm with Pizzasgood and jmarsden completely on the best way to sort out package management, by the way. Add a little more functionality to Pupget and there you have it. Dotpup works fine as is, and the squash files are only for very large applications. Just my 2c.

Nathan

[GuestToo]

Add a little more functionality to Pupget and there you have it. Dotpup works fine as is, and the squash files are only for very large applications

i think dotpups work the way they were intended, but it's trivially easy to add functionality ... i certainally have no objections to adding support tools for dotpups ... i do think that some people have misunderstood what the dotpup system is and was intended to be (a "simple installer" is a good description, though it is flexible enough to not be limited to being an installer)

i have not use Klik, but i think it works by converting .debs to cramfs files ... i'm not sure how it handles the limited number of loop devices

[GuestToo]

i'm not at all sure that Puppy needs a relatively complex package management system ... Slack and the many (about 30 anyway) distros based on Slack do not seem to need one ... and most of these distros, like Slax and Klax and Vector, were not intended to be simple console-mode servers to be used only by the technologically un-challenged ... there seems to be an unspoken assumption that Puppy absolutely and vitally requires a package management system, and it is essential that it be implemented immediately ... and this may be true, of course

some questions about dotpups that may not have been asked:

the dotpup system was conceived when Puppy did not have any package capabilities, other than downloaded 4 or 5 packages to my-applications and rebooting (F-port, Lua, xsane ...) ... /usr was read-only ... Unleashed did not exist .. pupget did not exist ... it was difficult to install software, and there was no easy way to make a package that a newbie could install

was the dotpup system even a good idea? did it serve a useful purpose, even for a short time?

Puppy has changed quite a bit ... /usr is now writable (though it is an inhospitable environment ... files you put there might be removed at any time, though that includes configuration files in /root too)

has Puppy outgrown the dotpup system? is it still useful?

for myself, my personal opinion is that it was and is still useful ... i do think that pupget packages have not been used as much as they could have been (i think a few dotpup packages might have been better as pupget packages)

[PeterSieg]

Hi.

was the dotpup system even a good idea? did it serve a useful purpose, even for a short time?

Puppy has changed quite a bit ... /usr is now writable (though it is an inhospitable environment ... files you put there might be removed at any time, though that includes configuration files in /root too)

has Puppy outgrown the dotpup system? is it still useful?

I say, the DotPup's are GREAT! They reassemble the Win$ Style of an
installer. Download and click on them and they will install and place a
menu entry and/or desktop icon.. That's the way it should work!

And we have all these nice additional apps surrounding the dotpups,
like MU's dotpup maker, convert source trees into dotpups, rpms into
dotpups etc..

I rather would say, promote the dotpups to THE puppy enhancements
package system!

There could be still some additional functionallity build into the dotpup
installer.. For ex. running ldd on the executables and check for missing
libs etc.. check for puppy version.. always offer also uninstall item in menu
system..

PS

[GuestToo]

They reassemble the Win$ Style of an installer

that was the main idea ... so Windows users would find it easy to use

check for puppy version

my SP107 dotpup package does this ... so that it will only install on Puppy 1.0.7

it's easy to make a dotpup package do exactly what you want, because it is very flexible (basically, it does whatever the script says to do) ... extended functionality can be easily added to the system without needing to re-write the dotpup handler ... enhancements and additional functionallity like MU's dotpup maker and tools to add to wm menus just make dotpups (and Puppy) better, i think ... it's ok with me if some dotpup packages register with pupget ... the advantage is that PCCC will include them when it builds an iso ... i have been mostly installing programs in /root, and i have not been registering my packages (they don't need to be, unless you want it saved by PCCC ... i think if i really wanted a package to be recognized and saved by PCCC, i would make a pupget package)

[Lobster]

A new catalogue of available .pups
New Index of Additional Software (Dotpups catalogued)BETA
is now avilable as sticky on the Additional Software and dotpups section of the forum.

meanwhile:
I will explain how I find extra programs for specialist needs:

I am now starting to store my most used programs on /mnt/home
(my hard drive)

I always use pupget first
then I would use the new (Dotpups catalogued)BETA

For a while I made extensive use of MU's program - which is nearly as simple as pupget (it contains more info though) to use. Often however the programs were not on the wiki pages (where MU's program searched)

I would then go and look in the grafpup depository
then I would check out any .sfs

I might even finally look for a required program through Linux google and see if I can install or if not suggest creation on the forum

As an end user the pupget front end followed by MU's is the simplest

What every programmer forgets - It is the front end that is important to usage. My first forage into Linux Land - I got Linux working and then found to my horror that installing was a nightmare of dependencies. Horrible.
Is pupget hard - no it is easy. Easier than anything that I have seen which works in fact.
Dotpups? Simple enough.

If the wiki is updated (a great task for a puppy enthusiast) then MU's frontend program becomes updated

.pups, pupgets, .sfs or even a new secure .pet?

What can I say we have too many progs
but I want MORE!

The first time I created a .pup - it took some commitment and a lot of help - I learnt a lot. Now it is simpler. As GuestToo keeps saying that simplicity of using is important.

So any new system has to be easy to create for (even if using existing technologies) and easy to use. If it is useful it may be adopted.

[Pizzasgood]

What can I say we have too many progs
but I want MORE! ;lol;

I was listening to "I Like It, I Love It" by Tim McGraw when I read that line. Strange coincidence. Definately lightened up a dark night.

I almost feel like we need something cleaner than the Pupget/PCC/upgrading deal we currently have. Maybe have a way to set within the package whether it should or shouldn't be wiped out in an upgrade (default=preserve). Then the textfile storing all the registered files could have another column for whether it is kept or eliminated.
The actuall script itself would accept a bunch of parameters so it could be used as a command by something else. Then something else could use it to do stuff, like regestering and whatnot. It should definately be commandline compatible, because someday there will be a CLI only Puppy, in which case you would still want use it to install stuff. It doesn't need a fancy interface, just to be useable (pupget +lameX.X.X.pet, pupget --listinstalled, pupget --listavailiable). That way, someone can write a separate frontend. Not just for CLI, but for GUI also.

For example, my Mo-Betta Wallpaper-Setta uses the interface Barry made, but if you decide you want a nicer one that previews the image and all, you could write it, and it could just use the already existing Mo-Betta Wallpaper-Setta to set the actual wallpaper.

Puppy doesn't neccessarily need something complex, but it needs something expandible and flexible. Whether it's one script (.pet) or a library of tools used by dotpup, it needs to be capible of being upgraded in the future just in case.

Personally, I think beefing-up/cleaning-up Pupget into the .pet system would be ideal for standard packages, and keeping dotpup would be good for those oddball packages.