![](https://secure.gravatar.com/avatar/3371841f302287e45e2408fad2234942.jpg?s=120&d=mm&r=g)
Originally Johannes Winkelmann wrote:
Hi there, Hello, dear devs!
Regarding PkgutilsIdeas:
[...]
Comments both on the wiki pages and the rest of this mail are highly welcome.
I've read all wiki pages, and I'm highly interested in package format of future CRUX packages. Well, I had couple of ideas recently about creating some sort of package format for CRUX. The goals to achieve, where: 1) simplicity 2) compatibility with existing pkgutils as much as possible 3) optionality 4) ability to install CRUX over the net entirely from binary packages The mentioned metadata is proposed to store in magical /ATTRIBUTES directory within a package in some form of attribute sets. I'd like to suggest my own solution I've reached some time ago in my dreams :) Actually there is a problem for me to maintain a dozen of CRUX PCs, including regular updates and automated installs with further configuring. I know that pkg-get and pkgsync are great tools, their help is precious. So my idea: Within a package archive in /var/lib/pkg/<packagename> is stored the entire port the package was built from. This is fairly simple :) This is very optional as soon as it is easy to disable such metadata include. This is very compatible, since you can use current pkgadd/prt-get to handle such packages. This is very flexible: simply saying, within /var/lib/pkg the some sort of 'local' ports tree is created. This gives an ability to rebuild the system easly in case of crash without worrying about different ports versions. This allows 'binary installs', - as soon as Pkgfile with all headers is included in a package, some script can easly process this information. This allows to create a centralized storage of some vital or heavy to compile packages. Also this allows users to create their own binary storage in order to do such installs: once the package is compiled it can be used further on a different CRUX box or after reinstalling existing CRUX box :) This also gives the ability to rebuilt the package. The other feature is that this method does not require further maintanance since the package format is prograssing in steps of ports tree. And finally this gives a very little overhead on package size - as soon as footprints are useless in packages. An advantage of such method over special /ATTRIBUTES directory is obvious: the package doesn't need special handling. But introducing /ATTRIBUTES means almost all existing package-related stuff of CRUX need to be rewrited. One can handle the local ports three in /var/lib/pkg/ as he/she wishes - even to delete it without any danger to package system itself. These were my thoughts. I felt I need to share them with you. Anyway I also appreciate any comments on these thoughs and any health critics as well :) -- Hope this was interesting, Oleksiy