Puppy Linux Discussion Forum Forum Index Puppy Linux Discussion Forum
Puppy HOME page : puppylinux.com
"THE" alternative forum : puppylinux.info
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

The time now is Wed 22 Oct 2014, 18:11
All times are UTC - 4
 Forum index » Advanced Topics » Cutting edge
Add support for other compressions than gzip for dotPets
Moderators: Flash, Ian, JohnMurga
Post new topic   Reply to topic View previous topic :: View next topic
Page 2 of 2 [30 Posts]   Goto page: Previous 1, 2
Author Message
Ibidem

Joined: 25 May 2010
Posts: 501
Location: State of Jefferson

PostPosted: Fri 22 Nov 2013, 16:22    Post subject:  

Debian format is actually pretty basic:
an ar archive containing two tarballs (control.tar.* & data.tar.*) and "debian-binary", which is a version stamp.
In control.tar.gz is a description (./control) and md5sums for the files installed (./md5sums).

So one could more or less duplicate it by installing to $INSTDIR then going
Code:
cd $INSTDIR; find * -type f -exec md5sum '{}' \; | tac > ../md5sums
tar -c * |gzip -9c > ../data.tar.gz
cd ..
#write a file called "control" containing the description
tar -c ./control ./md5sums | gzip -9c >control.tar.gz
echo "2.0" > debian-binary
ar rc new.deb debian-binary control.tar.gz data.tar.gz


rpm is an underdocumented header prepended to a compressed cpio archive. To create it, you can use rpm, rpm5, or xrpm

Now, is *.pet/pxt/... multiple formats?
Not really. Tar autodetects compression type. So you don't need _any_ new code, apart from mime types.

PS: there is at least one other archiver that could work for packaging: pax.
There's also the SVRx package tools (heirloom packagetools being the relevant port), but _so far_ no one has used those.
Back to top
View user's profile Send private message 
SFR


Joined: 26 Oct 2011
Posts: 1078

PostPosted: Sat 23 Nov 2013, 14:48    Post subject:  

Just for the record: there's also pfs format (discovered by me yesterday, anyone knew about this one?), used in PuppyRus.
http://wiki.puppyrus.org/puppyrus/pr218/pfs (google translate helps Wink )
ftp://mirror.yandex.ru/puppyrus/puppyrus/repository/pfs-utils-0.3.4-pr.pfs
Might be worth to investigate...

Greetings!

_________________
[O]bdurate [R]ules [D]estroy [E]nthusiastic [R]ebels => [C]reative [H]umans [A]lways [O]pen [S]ource
Omnia mea mecum porto.
Back to top
View user's profile Send private message 
mikeb


Joined: 23 Nov 2006
Posts: 8345

PostPosted: Sat 23 Nov 2013, 15:15    Post subject:  

Quote:
Debian format is actually pretty basic:
an ar archive containing two tarballs (control.tar.* & data.tar.*) and "debian-binary", which is a version stamp.

Perhaps there is an element of re-inventing the wheel here.

Is there a reason why puppy packages cannot be packaged in deb format.?.... they are used all the time with ubuntu based puppies and 95% of my software and libraries comes from deb land. Also that version stamp doo dah might be used in a way to help avoid such as forum packages ending up being installed to incompatible puppy versions. It might be an established format but effectively be a move forward for puppy. Also, as mentioned, higher compression could be used transparently as an option.

mike
Back to top
View user's profile Send private message 
Ibidem

Joined: 25 May 2010
Posts: 501
Location: State of Jefferson

PostPosted: Sat 23 Nov 2013, 17:54    Post subject:  

mikeb wrote:
Quote:
Debian format is actually pretty basic:
an ar archive containing two tarballs (control.tar.* & data.tar.*) and "debian-binary", which is a version stamp.

Perhaps there is an element of re-inventing the wheel here.

Is there a reason why puppy packages cannot be packaged in deb format.?.... they are used all the time with ubuntu based puppies and 95% of my software and libraries comes from deb land. Also that version stamp doo dah might be used in a way to help avoid such as forum packages ending up being installed to incompatible puppy versions. It might be an established format but effectively be a move forward for puppy. Also, as mentioned, higher compression could be used transparently as an option.

mike

The version stamp is a package format version, not a system version.

By the way, new compression systems are not always completely transparent.
The archiver autodetects compression based on filename extension or on the file magic.
If you use the .pet format, with a constant extension, yes it can be completely transparent...
If you use deb, you will be using (for example) data.tar.xz/control.tar.xz instead of data.tar.gz/control.tar.gz.
And the change in the name of the files has the potential to require a few lines of code.
Back to top
View user's profile Send private message 
mikeb


Joined: 23 Nov 2006
Posts: 8345

PostPosted: Sat 23 Nov 2013, 18:12    Post subject:  

Ah ok ...thanks for the clarification

mike
Back to top
View user's profile Send private message 
amigo

Joined: 02 Apr 2007
Posts: 2258

PostPosted: Sun 24 Nov 2013, 03:36    Post subject:  

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.
Back to top
View user's profile Send private message 
Ibidem

Joined: 25 May 2010
Posts: 501
Location: State of Jefferson

PostPosted: Mon 25 Nov 2013, 01:35    Post subject:  

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.
Back to top
View user's profile Send private message 
amigo

Joined: 02 Apr 2007
Posts: 2258

PostPosted: Mon 25 Nov 2013, 02:25    Post subject:  

"makes development more boring" What's boring about it? Creating good packages is a worthy goal. Anyone who wants to create packages should be concerned about the quality of them. And from a developers stand-point, software which helps to create good packages is quite a challenge -far from boring.
Back to top
View user's profile Send private message 
mikeb


Joined: 23 Nov 2006
Posts: 8345

PostPosted: Mon 25 Nov 2013, 06:51    Post subject:  

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. Very Happy

mike
Back to top
View user's profile Send private message 
amigo

Joined: 02 Apr 2007
Posts: 2258

PostPosted: Mon 25 Nov 2013, 13:26    Post subject:  

"Bring back pups"
-1
Sorry, only thing worse than *.pets are *.pups.
Back to top
View user's profile Send private message 
mikeb


Joined: 23 Nov 2006
Posts: 8345

PostPosted: Mon 25 Nov 2013, 13:28    Post subject:  

Bring back pups was my attempt at humour... more like black comedy really Very Happy

mike
Back to top
View user's profile Send private message 
amigo

Joined: 02 Apr 2007
Posts: 2258

PostPosted: Mon 25 Nov 2013, 14:55    Post subject:  

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.
Back to top
View user's profile Send private message 
Iguleder


Joined: 11 Aug 2009
Posts: 1923
Location: Israel, somewhere in the beautiful desert

PostPosted: Sat 07 Dec 2013, 10:09    Post subject:  

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.

_________________
My homepage
Back to top
View user's profile Send private message Visit poster's website MSN Messenger 
ICQ Number 
amigo

Joined: 02 Apr 2007
Posts: 2258

PostPosted: Sat 07 Dec 2013, 11:47    Post subject:  

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.
Back to top
View user's profile Send private message 
Ibidem

Joined: 25 May 2010
Posts: 501
Location: State of Jefferson

PostPosted: Wed 11 Dec 2013, 23:03    Post subject:  

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.

It's extract-only, and it only supports CRC32/CRC64 integrity checks (with a config option to ignore other types instead of failing).
But xz-embedded is what the kernel uses for XZ support.
Back to top
View user's profile Send private message 
Display posts from previous:   Sort by:   
Page 2 of 2 [30 Posts]   Goto page: Previous 1, 2
Post new topic   Reply to topic View previous topic :: View next topic
 Forum index » Advanced Topics » Cutting edge
Jump to:  

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Powered by phpBB © 2001, 2005 phpBB Group
[ Time: 0.0857s ][ Queries: 13 (0.0060s) ][ GZIP on ]