The actual archive and compression format are the least significant aspect of a package. It's arriving at correct, sane, usable content which is the hardest, followed by doing the correct, sane thing with that content when it is deployed on the system.
In other words, the real work is done by the software which creates the packages and the software which installs the content. The package 'format' is simply an agreed-on 'protocol' used by both.
The one thing that is really missing for puppy is a system of building *packages*. A system which builds a whole from scattered parts is not the same things and been shown to be unmaintainable. Otherwise, later puppies would not contain the same bugs and old software as used before. Only by reducing the work into logical, reasonable, workable units can upgrades and bug-fixes be possible for existing systems. This is why woof is such an awful idea. Now, if it were a method of assembling a bunch of separate *native* packages into a whole, then you'd have a winner every time. But, without build repeatability at the package level, builds of the 'whole' will always have things which need fixing manually. Of course, a proper package manager is needed to deploy the packages and make them usable.
Add support for other compressions than gzip for dotPets
amigo:
Agreed as to what puppy needs.
But that will mean the end of dpups/upups/spups and the like.
It also makes development more boring.
FYI, that is also an issue for (at least) CentOS and Scientific Linux.
If Redhat has a build system, it is not public, so the main clones are built by hand.
And there are occasional cases where they can't duplicate what Redhat provided.
Agreed as to what puppy needs.
But that will mean the end of dpups/upups/spups and the like.
It also makes development more boring.
FYI, that is also an issue for (at least) CentOS and Scientific Linux.
If Redhat has a build system, it is not public, so the main clones are built by hand.
And there are occasional cases where they can't duplicate what Redhat provided.
Agreed nothing more boring than endless bug fixing and wasting time on incompatible packages.
Woof perpetuates long standing bugs and restrains the system to a particular framework... very boring too. If I wanted to build a say slackware 14 based pup I would not need woof, just the packages from slackware.
Actually when pets appeared I thought (hoped) they were slackware tgz with a custom install script/meta data but unfortunately it turned out the file tree is in a folder so preventing direct extraction. A package adds files to the tree and may need to run a script and check itself and system version.... it should be simple by its nature.
Bring back pups ... they were interesting.
mike
Woof perpetuates long standing bugs and restrains the system to a particular framework... very boring too. If I wanted to build a say slackware 14 based pup I would not need woof, just the packages from slackware.
Actually when pets appeared I thought (hoped) they were slackware tgz with a custom install script/meta data but unfortunately it turned out the file tree is in a folder so preventing direct extraction. A package adds files to the tree and may need to run a script and check itself and system version.... it should be simple by its nature.
Bring back pups ... they were interesting.
mike
I was pretty sure you were kidding...
I really ought to stop writing these replies -it keeps from working on that new package format and the tools to create and manage them... Getting pretty interesting -this is the third complete re-write of the package spec, so it should be getting really good by now... Working out the best way of speeding up database searches through careful modelling of the database files.
I really ought to stop writing these replies -it keeps from working on that new package format and the tools to create and manage them... Getting pretty interesting -this is the third complete re-write of the package spec, so it should be getting really good by now... Working out the best way of speeding up database searches through careful modelling of the database files.
- Iguleder
- Posts: 2026
- Joined: Tue 11 Aug 2009, 09:36
- Location: Israel, somewhere in the beautiful desert
- Contact:
Just discovered xzminidec from XZ Embedded.
A 64-bit, static build against musl is 88 KB. I think Puppy could benefit a lot from a static binary included in woof-CE - its memory usage should be lower than that of the full XZ.
A 64-bit, static build against musl is 88 KB. I think Puppy could benefit a lot from a static binary included in woof-CE - its memory usage should be lower than that of the full XZ.
[url=http://dimakrasner.com/]My homepage[/url]
[url=https://github.com/dimkr]My GitHub profile[/url]
[url=https://github.com/dimkr]My GitHub profile[/url]
It's extract-only, and it only supports CRC32/CRC64 integrity checks (with a config option to ignore other types instead of failing).amigo wrote:That (xz-embedded) is interesting -but only because it's from the same author as the original xz. I'd still worry that it might lack some important functionality.
But xz-embedded is what the kernel uses for XZ support.