packdude

Under development: PCMCIA, wireless, etc.
Message
Author
User avatar
Iguleder
Posts: 2026
Joined: Tue 11 Aug 2009, 09:36
Location: Israel, somewhere in the beautiful desert
Contact:

packdude

#1 Post by 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:

Code: Select all

[Tue May  6 12:55:09 2014](INFO): Fetching the package database from <censored>
[Tue May  6 12:55:10 2014](INFO): Downloading mtpaint-git05052014.dude
[Tue May  6 12:55:11 2014](INFO): Verifying the integrity of ./var/packdude/archive/mtpaint-git05052014.dude
[Tue May  6 12:55:11 2014](INFO): Downloading libjpeg_turbo-1.3.0.dude
[Tue May  6 12:55:11 2014](INFO): Verifying the integrity of ./var/packdude/archive/libjpeg_turbo-1.3.0.dude
[Tue May  6 12:55:11 2014](INFO): Downloading musl-1.1.0.dude
[Tue May  6 12:55:12 2014](INFO): Verifying the integrity of ./var/packdude/archive/musl-1.1.0.dude
[Tue May  6 12:55:12 2014](INFO): Downloading linux_headers-2.6.32.61.dude
[Tue May  6 12:55:14 2014](INFO): Verifying the integrity of ./var/packdude/archive/linux_headers-2.6.32.61.dude
[Tue May  6 12:55:14 2014](INFO): Unpacking linux_headers
[Tue May  6 12:55:14 2014](INFO): Registering linux_headers
[Tue May  6 12:55:14 2014](INFO): Sucessfully installed linux_headers
[Tue May  6 12:55:14 2014](INFO): Unpacking musl
[Tue May  6 12:55:14 2014](INFO): Registering musl
[Tue May  6 12:55:14 2014](INFO): Sucessfully installed musl
[Tue May  6 12:55:14 2014](INFO): Unpacking libjpeg_turbo
[Tue May  6 12:55:14 2014](INFO): Registering libjpeg_turbo
[Tue May  6 12:55:14 2014](INFO): Sucessfully installed libjpeg_turbo
[Tue May  6 12:55:14 2014](INFO): Downloading libpng-1.6.10.dude
[Tue May  6 12:55:14 2014](INFO): Verifying the integrity of ./var/packdude/archive/libpng-1.6.10.dude
[Tue May  6 12:55:14 2014](INFO): Downloading zlib-1.2.8.dude
[Tue May  6 12:55:14 2014](INFO): Verifying the integrity of ./var/packdude/archive/zlib-1.2.8.dude
[Tue May  6 12:55:14 2014](WARNING): musl is already installed; skipping
[Tue May  6 12:55:14 2014](INFO): Unpacking zlib
[Tue May  6 12:55:14 2014](INFO): Registering zlib
[Tue May  6 12:55:14 2014](INFO): Sucessfully installed zlib
[Tue May  6 12:55:14 2014](INFO): Unpacking libpng
[Tue May  6 12:55:14 2014](INFO): Registering libpng
[Tue May  6 12:55:14 2014](INFO): Sucessfully installed libpng
[Tue May  6 12:55:14 2014](INFO): Downloading tiff-4.0.3.dude
[Tue May  6 12:55:21 2014](INFO): Verifying the integrity of ./var/packdude/archive/tiff-4.0.3.dude
[Tue May  6 12:55:21 2014](WARNING): musl is already installed; skipping
[Tue May  6 12:55:21 2014](WARNING): zlib is already installed; skipping
[Tue May  6 12:55:21 2014](WARNING): libjpeg_turbo is already installed; skipping
[Tue May  6 12:55:21 2014](INFO): Unpacking tiff
[Tue May  6 12:55:22 2014](INFO): Registering tiff
[Tue May  6 12:55:22 2014](INFO): Sucessfully installed tiff
[Tue May  6 12:55:22 2014](INFO): Downloading gifsicle-1.82.dude
[Tue May  6 12:55:22 2014](INFO): Verifying the integrity of ./var/packdude/archive/gifsicle-1.82.dude
[Tue May  6 12:55:22 2014](INFO): Downloading giflib-4.2.3.dude
[Tue May  6 12:55:22 2014](INFO): Verifying the integrity of ./var/packdude/archive/giflib-4.2.3.dude
[Tue May  6 12:55:22 2014](WARNING): musl is already installed; skipping
[Tue May  6 12:55:22 2014](INFO): Unpacking giflib
[Tue May  6 12:55:22 2014](INFO): Registering giflib
[Tue May  6 12:55:22 2014](INFO): Sucessfully installed giflib
[Tue May  6 12:55:22 2014](INFO): Unpacking gifsicle
[Tue May  6 12:55:22 2014](INFO): Registering gifsicle
[Tue May  6 12:55:22 2014](INFO): Sucessfully installed gifsicle
[Tue May  6 12:55:22 2014](INFO): Unpacking mtpaint
[Tue May  6 12:55:22 2014](INFO): Registering mtpaint
[Tue May  6 12:55:22 2014](INFO): Sucessfully installed mtpaint
Removal of mtPaint:

Code: Select all

[Tue May  6 12:56:45 2014](INFO): Fetching the package database from <censored>
[Tue May  6 12:56:45 2014](INFO): Removing files installed by mtpaint
[Tue May  6 12:56:45 2014](INFO): Unregistering mtpaint
[Tue May  6 12:56:45 2014](INFO): Successfully removed mtpaint
[Tue May  6 12:56:45 2014](INFO): Cleaning up unneeded packages
[Tue May  6 12:56:45 2014](INFO): Removing files installed by libpng
[Tue May  6 12:56:45 2014](INFO): Unregistering libpng
[Tue May  6 12:56:45 2014](INFO): Successfully removed libpng
[Tue May  6 12:56:45 2014](INFO): Removing files installed by tiff
[Tue May  6 12:56:45 2014](INFO): Unregistering tiff
[Tue May  6 12:56:45 2014](INFO): Successfully removed tiff
[Tue May  6 12:56:45 2014](INFO): Removing files installed by gifsicle
[Tue May  6 12:56:45 2014](INFO): Unregistering gifsicle
[Tue May  6 12:56:45 2014](INFO): Successfully removed gifsicle
[Tue May  6 12:56:45 2014](INFO): Removing files installed by libjpeg_turbo
[Tue May  6 12:56:45 2014](INFO): Unregistering libjpeg_turbo
[Tue May  6 12:56:45 2014](INFO): Successfully removed libjpeg_turbo
[Tue May  6 12:56:45 2014](INFO): Removing files installed by zlib
[Tue May  6 12:56:45 2014](INFO): Unregistering zlib
[Tue May  6 12:56:45 2014](INFO): Successfully removed zlib
[Tue May  6 12:56:45 2014](INFO): Removing files installed by giflib
[Tue May  6 12:56:45 2014](INFO): Unregistering giflib
[Tue May  6 12:56:45 2014](INFO): Successfully removed giflib
[Tue May  6 12:56:45 2014](INFO): Removing files installed by musl
[Tue May  6 12:56:46 2014](INFO): Unregistering musl
[Tue May  6 12:56:46 2014](INFO): Successfully removed musl
[Tue May  6 12:56:46 2014](INFO): Removing files installed by linux_headers
[Tue May  6 12:56:46 2014](INFO): Unregistering linux_headers
[Tue May  6 12:56:46 2014](INFO): Successfully removed linux_headers
Missing Features

- Package categories and description (easy to add, nothing but more two columns in the database 8))
- Package updating
- Integration with PPM's gtkdialog interface - I think it would be amazing if I could replace PPM's backend with packdude, but keep the same interface - zero headaches for users, but greatly improved performance and robustness.

Building

You'll need GCC, make, Git, libcurl, sqlite3 and libarchive to build packdude. The devx of all modern Puppies should contain all these packages, but may lack libarchive.

Code: Select all

git clone https://github.com/iguleder/packdude.git
cd packdude
make
Testing

By default, packdude is configured to use a repository of static 64-bit packages I built for personal use. You can use these packages on any 64-bit distro, including Slacko64 and Fatdog.

You can try out packdude without doing any damage to your system, by using an installation prefix:

Code: Select all

mkdir -p /tmp/var/packdude/archive
packdude -p /tmp -i mtpaint
In this example, packdude installs mtPaint to /tmp. Before you run packdude with "-p", make sure you create the specified directory and /var/packdude/archive under it.

If anything fails or takes a long time, you can re-run packdude with "-d" to get tons of debugging information:

Code: Select all

packdude -p /tmp -i mtpaint -d
Here are four examples for things you can do with packdude.

Test Case #1

Install two packages with some common dependencies:

Code: Select all

packdude -i tinyxserver -p /tmp
packdude -i libpng -p /tmp
tinyxserver pulls in zlib and packdude should notice it's already installed, when it installs libpng.

Test Case #2

Install two packages with a common dependency, then remove one of them. The common dependency should remain installed:

Code: Select all

packdude -i mtpaint  -p /tmp
packdude -i rox -p /tmp

packdude -r mtpaint -p /tmp

packdude -r rox -p /tmp
In this case, both mtPaint and ROX-Filer depend on libpng. It should remain installed after mtPaint is removed, but packdude's automatic cleanup should remove it once ROX-Filer is removed, because no package requires it anymore.

Test Case #3

Install a package, then install multiple packages that depend on it and remove them. The first package should remain installed, because it was installed by the user and not as a dependency.

Code: Select all

packdude -i zlib -p /tmp

packdude -i mtpaint -p /tmp
packdude -i tinyxserver -p /tmp
packdude -i rox -p /tmp
packdude -i lazy_utils -p /tmp
packdude -i dropbear -p /tmp
packdude -i bftpd -p /tmp
packdude -i curl -p /tmp

packdude -r mtpaint -p /tmp
packdude -r tinyxserver -p /tmp
packdude -r rox -p /tmp
packdude -r lazy_utils -p /tmp
packdude -r dropbear -p /tmp
packdude -r bftpd -p /tmp
packdude -r curl -p /tmp
zlib should remain installed, while all other packages are removed without leaving a trace.

Test Case #4

Install packdude using packdude :lol:

Code: Select all

packdude -i packdude -p /tmp
[url=http://dimakrasner.com/]My homepage[/url]
[url=https://github.com/dimkr]My GitHub profile[/url]

User avatar
mavrothal
Posts: 3096
Joined: Mon 24 Aug 2009, 18:23

Re: packdude

#2 Post by mavrothal »

Iguleder wrote:packdude

<snip>

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).

<snip>
  • Support for one, hardcoded repository
  • repodude, a repository database generator, inspired by createrepo
Very exciting :D

But do you actually say to duplicate the entire debian and slackware repos or process the repo metadata in a way that packdude could understand but do the downloading from the original debia/slackware repos?
== [url=http://www.catb.org/esr/faqs/smart-questions.html]Here is how to solve your[/url] [url=https://www.chiark.greenend.org.uk/~sgtatham/bugs.html]Linux problems fast[/url] ==

User avatar
Iguleder
Posts: 2026
Joined: Tue 11 Aug 2009, 09:36
Location: Israel, somewhere in the beautiful desert
Contact:

#3 Post by 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.
[url=http://dimakrasner.com/]My homepage[/url]
[url=https://github.com/dimkr]My GitHub profile[/url]

User avatar
neerajkolte
Posts: 516
Joined: Mon 10 Feb 2014, 07:05
Location: Pune, India.

Re: packdude

#4 Post by neerajkolte »

Iguleder wrote:packdude
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).
Nice idea, I will test it on my Fatdog64-630 and report back.
Thanks
"One of my most productive days was throwing away 1000 lines of code."
- Ken Thompson

“We tend to overestimate the effect of a technology in the short run and underestimate the effect in the long run.â€￾
- Amara’s Law.

User avatar
mavrothal
Posts: 3096
Joined: Mon 24 Aug 2009, 18:23

#5 Post by mavrothal »

Iguleder wrote: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.
It just looks like a maintenance headache (regular repo updates) and a big unnecessary duplication. In addition if you host binary packages, you should also host the sources (according to GPL), further increasing size and maintenance headaches.
Since conversion scripts will be/have been developed why not use a frond end to download and covert the package from the original and then pass it to packdude for further processing. In most (all?) cases you will just need to process only the package metadata and or install scripts, so it should be fast.
This way down the road additional repos/distros can be used. even the pets that are spread all over the place :D
== [url=http://www.catb.org/esr/faqs/smart-questions.html]Here is how to solve your[/url] [url=https://www.chiark.greenend.org.uk/~sgtatham/bugs.html]Linux problems fast[/url] ==

User avatar
neerajkolte
Posts: 516
Joined: Mon 10 Feb 2014, 07:05
Location: Pune, India.

#6 Post by 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

Code: Select all

# git clone https://github.com/iguleder/packdude.git
Cloning into 'packdude'...
remote: Reusing existing pack: 160, done.
remote: Counting objects: 36, done.
remote: Compressing objects: 100% (36/36), done.
remote: Total 196 (delta 6), reused 0 (delta 0)
Receiving objects: 100% (196/196), 566.28 KiB | 10 KiB/s, done.
Resolving deltas: 100% (90/90), done.
# cd packdude
# make
Package libarchive was not found in the pkg-config search path.
Perhaps you should add the directory containing `libarchive.pc'
to the PKG_CONFIG_PATH environment variable
No package 'libarchive' found
cc -c -o packdude.o packdude.c -O2 -pipe -std=gnu99 -Wall -pedantic -DVAR_DIR=\"/var\" -DARCH=\"x86_64\" -DPACKAGE=\"packdude\" -DVERSION=1 -DREPO=\"http://repo.dimakrasner.com:1024\" 
Package libarchive was not found in the pkg-config search path.
Perhaps you should add the directory containing `libarchive.pc'
to the PKG_CONFIG_PATH environment variable
No package 'libarchive' found
cc -c -o manager.o manager.c -O2 -pipe -std=gnu99 -Wall -pedantic -DVAR_DIR=\"/var\" -DARCH=\"x86_64\" -DPACKAGE=\"packdude\" -DVERSION=1 -DREPO=\"http://repo.dimakrasner.com:1024\" 
manager.c: In function 'manager_fetch':
manager.c:181:2: warning: string length '4526' is greater than the length '4095' ISO C99 compilers are required to support [-Woverlength-strings]
Package libarchive was not found in the pkg-config search path.
Perhaps you should add the directory containing `libarchive.pc'
to the PKG_CONFIG_PATH environment variable
No package 'libarchive' found
cc -c -o database.o database.c -O2 -pipe -std=gnu99 -Wall -pedantic -DVAR_DIR=\"/var\" -DARCH=\"x86_64\" -DPACKAGE=\"packdude\" -DVERSION=1 -DREPO=\"http://repo.dimakrasner.com:1024\" 
Package libarchive was not found in the pkg-config search path.
Perhaps you should add the directory containing `libarchive.pc'
to the PKG_CONFIG_PATH environment variable
No package 'libarchive' found
cc -c -o fetch.o fetch.c -O2 -pipe -std=gnu99 -Wall -pedantic -DVAR_DIR=\"/var\" -DARCH=\"x86_64\" -DPACKAGE=\"packdude\" -DVERSION=1 -DREPO=\"http://repo.dimakrasner.com:1024\" 
Package libarchive was not found in the pkg-config search path.
Perhaps you should add the directory containing `libarchive.pc'
to the PKG_CONFIG_PATH environment variable
No package 'libarchive' found
cc -c -o repo.o repo.c -O2 -pipe -std=gnu99 -Wall -pedantic -DVAR_DIR=\"/var\" -DARCH=\"x86_64\" -DPACKAGE=\"packdude\" -DVERSION=1 -DREPO=\"http://repo.dimakrasner.com:1024\" 
Package libarchive was not found in the pkg-config search path.
Perhaps you should add the directory containing `libarchive.pc'
to the PKG_CONFIG_PATH environment variable
No package 'libarchive' found
cc -c -o log.o log.c -O2 -pipe -std=gnu99 -Wall -pedantic -DVAR_DIR=\"/var\" -DARCH=\"x86_64\" -DPACKAGE=\"packdude\" -DVERSION=1 -DREPO=\"http://repo.dimakrasner.com:1024\" 
Package libarchive was not found in the pkg-config search path.
Perhaps you should add the directory containing `libarchive.pc'
to the PKG_CONFIG_PATH environment variable
No package 'libarchive' found
cc -c -o stack.o stack.c -O2 -pipe -std=gnu99 -Wall -pedantic -DVAR_DIR=\"/var\" -DARCH=\"x86_64\" -DPACKAGE=\"packdude\" -DVERSION=1 -DREPO=\"http://repo.dimakrasner.com:1024\" 
Package libarchive was not found in the pkg-config search path.
Perhaps you should add the directory containing `libarchive.pc'
to the PKG_CONFIG_PATH environment variable
No package 'libarchive' found
cc -c -o package.o package.c -O2 -pipe -std=gnu99 -Wall -pedantic -DVAR_DIR=\"/var\" -DARCH=\"x86_64\" -DPACKAGE=\"packdude\" -DVERSION=1 -DREPO=\"http://repo.dimakrasner.com:1024\" 
Package libarchive was not found in the pkg-config search path.
Perhaps you should add the directory containing `libarchive.pc'
to the PKG_CONFIG_PATH environment variable
No package 'libarchive' found
cc -c -o archive.o archive.c -O2 -pipe -std=gnu99 -Wall -pedantic -DVAR_DIR=\"/var\" -DARCH=\"x86_64\" -DPACKAGE=\"packdude\" -DVERSION=1 -DREPO=\"http://repo.dimakrasner.com:1024\" 
archive.c:6:21: fatal error: archive.h: No such file or directory
compilation terminated.
make: *** [archive.o] Error 1
# 
I have searched in Fatdog package manager but couldn't find it.
Thanks
"One of my most productive days was throwing away 1000 lines of code."
- Ken Thompson

“We tend to overestimate the effect of a technology in the short run and underestimate the effect in the long run.â€￾
- Amara’s Law.

User avatar
Iguleder
Posts: 2026
Joined: Tue 11 Aug 2009, 09:36
Location: Israel, somewhere in the beautiful desert
Contact:

#7 Post by 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). :)
[url=http://dimakrasner.com/]My homepage[/url]
[url=https://github.com/dimkr]My GitHub profile[/url]

darry1966

#8 Post by 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???????

User avatar
Iguleder
Posts: 2026
Joined: Tue 11 Aug 2009, 09:36
Location: Israel, somewhere in the beautiful desert
Contact:

#9 Post by 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.
[url=http://dimakrasner.com/]My homepage[/url]
[url=https://github.com/dimkr]My GitHub profile[/url]

darry1966

#10 Post by darry1966 »

Thanks Iguleder

It sounds really awesome what you are doing.

amigo
Posts: 2629
Joined: Mon 02 Apr 2007, 06:52

#11 Post by 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...

User avatar
Iguleder
Posts: 2026
Joined: Tue 11 Aug 2009, 09:36
Location: Israel, somewhere in the beautiful desert
Contact:

#12 Post by 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.
[url=http://dimakrasner.com/]My homepage[/url]
[url=https://github.com/dimkr]My GitHub profile[/url]

Ibidem
Posts: 549
Joined: Wed 26 May 2010, 03:31
Location: State of Jefferson

#13 Post by 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.

User avatar
Iguleder
Posts: 2026
Joined: Tue 11 Aug 2009, 09:36
Location: Israel, somewhere in the beautiful desert
Contact:

#14 Post by 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.
[url=http://dimakrasner.com/]My homepage[/url]
[url=https://github.com/dimkr]My GitHub profile[/url]

User avatar
puppyluvr
Posts: 3470
Joined: Sun 06 Jan 2008, 23:14
Location: Chickasha Oklahoma
Contact:

#15 Post by puppyluvr »

:D 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...
Close the Windows, and open your eyes, to a whole new world
I am Lead Dog of the
Puppy Linux Users Group on Facebook
Join us!

Puppy since 2.15CE...

User avatar
Iguleder
Posts: 2026
Joined: Tue 11 Aug 2009, 09:36
Location: Israel, somewhere in the beautiful desert
Contact:

#16 Post by Iguleder »

Now it's in good shape - I fixed another memory leak and added support for querying the package database. I did extensive testing in the past two weeks and it works very well.

Now, I want to add a package description field (for display in graphical frontends).

puppyluvr - I want the name to be generic and not associated with a single distro. As a community distro, we're very poor and I don't want to deter other distros from using this code, since that's the best way to lower the maintenance burden. When others use your code, they develop the motivation and man power to fix bugs and add more features.

EDIT: I just submitted committed many efficiency improvements. packdude is way faster now :D
[url=http://dimakrasner.com/]My homepage[/url]
[url=https://github.com/dimkr]My GitHub profile[/url]

slavvo67
Posts: 1610
Joined: Sat 13 Oct 2012, 02:07
Location: The other Mr. 305

#17 Post by slavvo67 »

Can I suggest implementing this as a pet, first? The shock of replacing PPM, regardless of how bad it is might be a lot to handle.

If possible, it might be better to allow for pet or sfs install and allow users to provide feedback first.

Best,

Slavvo67

User avatar
Iguleder
Posts: 2026
Joined: Tue 11 Aug 2009, 09:36
Location: Israel, somewhere in the beautiful desert
Contact:

#18 Post by Iguleder »

Backwards compatibility is easy to do. It's not that hard to unpack a PET package using C code. It's just a .tar.gz archive with the MD5 appended.

However, I see no reason to do this, because this makes the package manager design more complicated. Also, our PET repositories are really small - it's much easier to convert them to another format. For all the PETs hanging around in the forums, we could use a temporary, "pirate" PET installation tool which extracts packages to / and doesn't integrate with the new package manager.

I just added XZ support to packdude, so packages are tiny. I also added some efficiency improvements, so package download and installation is insanely fast now.

I decided to freeze the code and keep the current code base "stable". More features means more bugs and memory leaks, while at the moment, packdude already does everything I want it to. I might do a packdude 2.0, if I change my mind.
[url=http://dimakrasner.com/]My homepage[/url]
[url=https://github.com/dimkr]My GitHub profile[/url]

User avatar
mavrothal
Posts: 3096
Joined: Mon 24 Aug 2009, 18:23

#19 Post by mavrothal »

Iguleder wrote:Backwards compatibility is easy to do. It's not that hard to unpack a PET package using C code. It's just a .tar.gz archive with the MD5 appended.

However, I see no reason to do this, because this makes the package manager design more complicated. Also, our PET repositories are really small - it's much easier to convert them to another format. For all the PETs hanging around in the forums, we could use a temporary, "pirate" PET installation tool which extracts packages to / and doesn't integrate with the new package manager.
The problem with a "pirate" tool is that you also need a tool to record them and uninstall them, that looks like a second package manager.
If the "unofficial" pets are allowed, would be better if the package manager is aware of them and handle them properly. Maybe by including the pet conversion script/program that will be used to convert the pet repos, as a first step in the process.
== [url=http://www.catb.org/esr/faqs/smart-questions.html]Here is how to solve your[/url] [url=https://www.chiark.greenend.org.uk/~sgtatham/bugs.html]Linux problems fast[/url] ==

stemsee

packdude

#20 Post by stemsee »

When can we get it?
ht
Today i built Arch and trusty, but there is something wrong with my kernel (i hope it is only that!) I will rebuild a new kernel and insert it tonight. I would like to include packdude.

Post Reply