Puppy Linux Discussion Forum

[Iguleder]

packdude

I don't like PPM, because:
- It's slow as hell. It does lots of text processing using shell scripts, which is a big no-no.
- It's contaminated with huge amounts of old code and ugly hacks. It was born very long ago and keeps growing since then.
- Its native package format, PET, is poorly designed. It's the only package format I'm aware of, which has a sub-directory named after the package.
- Its repositories format is error-prone and doesn't work well with big repositories (annoying missing package errors in Woof).
- All stages in the process of creating PET packages are manual. Some are even graphical (dir2pet).

However, I don't think using another distro's package manager in Puppy is a good idea. If we go this way, I think pacman is the way to go. It's fast, easy to use and gets the job done. However:
- I think it could be even simpler and lighter.
- I don't see any reason why a package manager should ask questions.
- I think it's nice to have a package manager that does maintenance tasks automatically, without prompting the user.

I think we should kick PPM and replace it with a simple and solid package manager. Support for Debian, Slackware or Ubuntu packages can be provided in the form of converted packages (i.e a tool that converts an entire Slackware repository into a "native" repository).

That's why I wrote packdude, a small package manager inspired by pacman, which supports only one, simple package format. I post it here as a "technology preview" - I'd like to hear more opinions about this idea and get some feedback.

It's still young, so its features are quite limited:

Package download and installation



• Fast and efficient package lookup, thanks to SQLite
  
• Lightweight decompression, using miniz (as opposed to LZMA2, as used by most major distros today)
  
• Fast package integrity verification, using the miniz CRC32 routine (instead of the zlib one)
  
• Support for multiple download protocols, via libcurl
  
• Fast, recursive dependencies resolution
  


• Package removal
  
  
  
  • Automatic, recursive cleanup of unneeded dependencies
    
  
  
• Repositories
  
  
  
  • Support for one, hardcoded repository
    
  • repodude, a repository database generator, inspired by createrepo
    
  
  
• Package creation
  
  
  
  • dudepack, a tool that converts tar archives into packages
    
  • dudeunpack, a package extraction tool
    
  
  
• Distro building
  
  
  
  • Support for working under a prefix as a regular user - i.e install packages to /tmp instead of /
    
  
  

packdude is designed to allow us to build a magical tool similar to debootstrap, which accepts an architecture (i.e x86_64) and a use case (i.e "Puppy for laptops with Xfce, please") and installs a clean Puppy system inside a directory.

Then, on top of that tool, we can build another tool, which converts a clean installed Puppy into a bootable ISO - a very thin and elegant tool that replaces woof-CE. This tool can used by remastering tools, too.

packdude is still considered experimental and may ruin your system. Use it at your own risk.

Sample Output

Installation of mtPaint:

[mavrothal]

[Iguleder]

Exactly.

Instead of a silly situation where every client has to go through that long conversion process, we'll do it just once, server-side. The user gets the same user experience, no matter where the packages came from.

EDIT: it should be very easy to do this. We already have those parsers in Woof - we just need to change the output format a little bit.

[neerajkolte]

[mavrothal]

[neerajkolte]

Hi Iguleder,
Could you possibly tell me where to get libarchive for fatdog64-630.
I have devx sfs loaded. Following is the output I have in terminal when I try to install packdude

[Iguleder]

Either take another distro's package (not recommended) or build it from source.

EDIT: I'm currently trying to build a bootable ISO using packdude - so far, it looks great. I wrote a debootstrap-like thing that installs the kernel, some user mode tools, tinyxserver, JWM and ROX-Filer and packdude itself to a directory (packdude -p in a loop, nothing fancy). Then, I took the code that generates an ISO image and put it in an independent script.

The second part works fine already, but the first is still running (my repository is slow as hell).

[darry1966]

Hi Iguleder,

I wish you my sincerest best with this project - one of the things that puts me off "modern" Puppies and some new users is the Puppy Package Manager and I agree a commanline/Gui package manager like pacman would be ace.

To be able to install packages from commandline would be cool.

Does this mean you could have a Debian net install type scenario for Puppy to have a customized install - in other words could what you are developing lead to this???????

[Iguleder]

Not exactly.

I want us to have a very fast tool that installs Puppy to a directory, with support for multiple targets (use cases, desktops, etc'). It's network-based like netinstall, but not a bootable image - it's an application you can run on any distro.

Then, scripts that build a Puppy ISO from an installed Puppy can be used to build a Puppy. You get easy remastering for free.

[darry1966]

Thanks Iguleder

It sounds really awesome what you are doing.

[amigo]

So, what does the package format look like?
Are there database files included in the package -or are the database entries generated while unpacking the archive?
Are there facilities for pre/post install/uninstall scripts?
What about upgrade/downgrade/replace actions?

I'm sure you haven't implemented all of these yet -I just want to get you thinking about them from the beginning -because the package format specification must include mechanisms for doing these things. The package format is the central thing to get right as soon as possible since the software for creating and managing the packages hangs from the package format.

Of course, the users here will want dependency resolution right away. But, as you have hinted in the OP, the layout and management of a package repository is also essential to managing dependencies. A central database of dependency information will not work because it is un-manageable. So, packages themselves have to be able to communicate this information -which means that the info must be available at package build-time.

For most systems this means having a pre-authored list of dependencies. The better alternative is to have dependency information *generated* at package build-time. This means building packages from freshly-built sources. The point here is that the package-creation software is the most important bit of code needed. This insures consistent creation of packages which fit the package format.

The package format can then transmit depends/conflicts info, script actions needed, pkg description info, etc., forward to the tools which install/upgrade the packages. The actual installation of a single package should be handled by CLI tools which can then be called by GUI applications, or other CLI tools which can 'manage' dependencies or installation scenarios.

I could go on -I love the subject of packages! But, I don't want to belabor or bore anyone here... I've already designed a couple of new package formats, along with the software for creating and managing them, so I might be able to help you think about some aspects which you may not have thought through yet -let me know, if so. Not many new package formats get created, so there aren't many chances to talk about it...

[Iguleder]

Still working on integration - since I use my own, new union file system, SQLite3 and packdude itself triggered three bugs.

So far, the whole thing works, but in a distro built using packdude, it's possible to install packages but their extraction fails at some point, so they're only partially-installed. I'm currently testing all the fixes I wrote.

[Ibidem]

Not immediate concerns, but some features that would be useful long-term.
-Can it install local packages?
-Support for file: repositories is very useful (makes for much faster installs, among other things)
It would probably speed up your testing a good bit.
-If you want to support debootstrap-type use, it _needs_ to support specifying a repository on the command line.
-In the distant future, multiple repositories would be helpful...

A netinstall system might be packdude, a shell, and a few key utilities (mainly networking tools, modprobe, mount, a partitioner, and mkfs). Debian has two flavors of netinstall; one has just the networking stuff and download the installer and all that at boot, the other has the full installer at the start.

[Iguleder]

I was thinking, maybe a -u parameter for specifying the repository is enough. If the user doesn't pass it, there is a hard coded fallback.

[puppyluvr]

Hello,
Sounds like a much needed upgrade.
The ability to parse metadata and convert packages from multiple distros would be awesome.
One thought:
If you build it specifically for Puppy,
Why not "Packdog" "Dogpack" and "Dogunpack"
Lol...