(old)Puppy Linux Discussion Forum

Everything (including documentation) is in GitHub - see the first post.

You'll have to set up a repository before you can use packdude.

How would I do it locally? adding a dvd, or directory such as /var/apt/cache or woof-ce local-repositories, for testing. So that if i wanted to use some packages from wheezy in a precise build i could use packdude to manage local repos as there is only one pet repo but several .deb repos. Or not?

Nope.

packdude has its own package format and repositories format. You'll have to convert Debian/Ubuntu repositories to packdude's format first.

The new pkg mgr is cool. I love that its expandable.

I just wanted to note that ppm could be 20x faster if the scripts used:
IFS="|"
while read field1 field2 ... fieldN: do

instead of the hacky hodge podge combo of read awk, grep, sed cut
... and others

shell does fine at text processing if its done right, unfortunately most scripters don't have a good understanding of the powerful built-ins.

to do the same in C, strsep or strtok (both are hellacious) are often used or fscanf with a special string that must account for versions with different number of fields. While it is still faster, the code can grow pretty complex ... and complexity has a cost, which is a perfectly good reason to use an actual database like sqlite or lmdb.

mavrothal wrote:In addition if you host binary packages, you should also host the sources (according to GPL)

No, it is perfectly legit to make the source available via snail mail on 8 inch floppies at the expense of any requester who cannot trust that they are the same as upstream. There was a whole debate on this with damn small linux ~10 years or so ago.

technosaurus wrote: I just wanted to note that ppm could be 20x faster if the scripts used:
IFS="|"
while read field1 field2 ... fieldN: do

instead of the hacky hodge podge combo of read awk, grep, sed cut
... and others

20x? wow!
PPM has about 700 of those. About 50 in tandem!
However, a lot of these are for writing in tmp for latter use...
Maybe you could provide a working example for one/any of the PPM scripts
(if you do, maybe in another thread - not to highjack this one)

It's fine - go ahead and hijack this thread. It has only one purpose - improve package management in Puppy.

I could probably help put together a script to convert pet .packages databases or pet.specs files directly into PDDB (pack dude database) with ash and sqlite3. Its just a matter of translating the columns into their respective database fields and writing an "INSERT into ...". The biggest thing that would slow that conversion process down would be trying to do each record one at a time. Sqlite can be pretty quick, but not if you open a database write 1 record and close it 1000 times ... better to open it write 1000 records and close it (this is why fastcgi is so much faster than cgi too)

Sounds like a good idea, I'll give it a go.

It's even easier - packdude's repository creation tool (repodude) accepts a CSV file very similar to Puppy's package lists. Conversion should be extremely easy.

EDIT: I have a working prototype here it's Puppy's "common" repository, converted to packdude's format. Build the latest packdude and use -u to force the use of this repository.

EDIT 2: it works! I was able to install a52dec. packdude's repositories are limited to one version of each package, so I had to filter only the most recent version of each package.

EDIT 3: Puppy's dependencies are a mess. PPM doesn't really handle dependencies, so some package specify non-existing ones, although they work just fine. For example - "urxvt" as a dependency of a gtkdialog-based package, while the right package name is "rxvt-unicode".

EDIT 4: I'm experimenting with taking things two steps forward. I'm trying to generate a self-hosting toolchain using the last GPLv2 versions of GCC and Binutils, plus the latest musl. I think it would be extremely cool to be able to install a very thin, Aboriginal-style distro to a directory using packdude, then build the entire distro (e.g all packages) inside a chroot environment.

're: self hosting

I have been wanting to do the same with llvm, but I forked binutils, gcc, mupdf gpl2 versions @github.com/technosaurus just in case.

Have you seen this. Might be some useful scripts in there.

http://4mlinux.blogspot.co.uk/2013/12/a ... m-txz.html

cheers

I'm aware of alien and I think it's nice, but I want something different - a repository converter. I want to convert a repository myself, so they user doesn't have to go through the slow conversion process locally.

Regarding compiler stuff, my GCC cross-compiler fails to build a native self. I'm trying to cross-compile a static GCC using Aboriginal's toolchain.

Iguleder wrote:Regarding compiler stuff, my GCC cross-compiler fails to build a native self. I'm trying to cross-compile a static GCC using Aboriginal's toolchain.

linuxfromscratch had a couple of patches for this problem... the autotools garbage messes up the 2nd pass iirc.

Sqlite should probably have been a standard feature in PUPs since smartPhones arrived years ago. 2 of the members here are WOOF-CE contributors. Please add for future PUPs as this PPM utility moves forward into mainstream.

One thing I never did like about PPM was the update process.
When run, it would attempt to update all repositories.
I would have preferred to be able to choose the ones that got updated.
And if one tries to interrupt the update process, the conversion of the file lists never gets completed and I have crashed PPM in the process.

WIll packdude have a graphical user display that shows available files in a repository?
Or is SQlite responsible for that?

sqlite is really simple to learn. if you're interested you can use puppy built-in sqlite3 shell to play. The csv format is ideal for gtkdialog trees/lists. I even wrote a patch to output json for use in a browser front-end. Hopefully I can get netsurf's new JavaScript engine to work or elinks with spidermonkey/libsee so it can be used in the console (see akita thread for last elinks with libsee support)

I wrote gpackdude, a dead-simple packdude frontend, with gtkdialog1. It allows you to install or remove packages. Inspiration came from Tiny Core's FLTK-based extension manager, but I don't like the use of C++ because of bloat and the challenge of cross-compiling static C++ binaries. Also, I really like GTK1

You don't have to worry about updating the database. In one of the latest commits, I made the repository package database cached. packdude will try to fetch the database without asking any questions, if it's one hour old. If you install multiple packages, packdude will update the database before the first installation.

If you look at the output of packdude -l and packdude -q, you'll notice it's exactly in the format of tree view entries in gtkdialog. You just have to wrap each output line with <item> tags. Here's the gpackdude code.

(screenshot taken under Xubuntu 14.04 x86_64)

It looks great! Very clear and logical. Any chance of a field for package size?

4Mlinux - even though it uses the word 'Alien' (noun) in the link it isn't alien (n) it is alien (adj). If you can't be bothered to have a look fair enough!

Intentionally, I decided to remove that field, for three reasons:
1) This allows developers to rebuild a defective package, without having to rebuild the database.
2) Size doesn't matter much, because packages are small thanks to xz compression. The internet connection of most users is fast enough to handle the download of packages in the size range of 80K to 1MB (most packages in the repository at the moment).
3) I believe people care more about functionality and less about size. If a user needs to convert an audio file and the only audio converter in the repository is ffmpeg, the user has to choose between installing a big package and giving up on that. Most users are sane and use their computers to do useful stuff.

Regarding alien - it's client-side and I want something server-side. Also, alien doesn't resolve dependencies. I'm talking about the old alien (https://en.wikipedia.org/wiki/Alien_(software)) - the 4M solution does the same thing.

I wanted to install a more appealing mixer the other day, I had a CHOICE! Qasmxer or qashctl or jackmixer or retrovol, I chose gmerlin, because it offered the same functionality in a smaller package size, and because I'm psychologically dysfunctional! Comes from the longest posterity.

"Most users are sane and use their computers to do useful stuff. " This is debatable and lacks consensus and empirical evidence, I would say relatively!

Peace be with you. Have a nice day!