Date: Fri, 11 May 2007 23:02:31 +0200 From: David Naylor <dragonsa@highveldmail.co.za> To: freebsd-hackers@freebsd.org Subject: DPS Initial Ideas Message-ID: <200705112302.35380.dragonsa@highveldmail.co.za>
next in thread | raw e-mail | index | archive | help
--nextPart1701573.s2DFBrc6Nc Content-Type: multipart/mixed; boundary="Boundary-01=_nnNRGI9yUkC+3An" Content-Transfer-Encoding: 7bit Content-Disposition: inline --Boundary-01=_nnNRGI9yUkC+3An Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi, Thank you all for your responses, it has given me much to think about. I=20 guess there is consenses that there is room for improvement in the current= =20 pkg system. Attached are some of my initial ideas about what is required a= nd=20 expected in any (and all future) package systems. =20 Since I am going away this weekend I have had limited time to work on this= =20 document and as such it is in early stages of development. My objective is= =20 to get a clear understanding and target of what is required for this new=20 package system. =20 I am looking at a hybrid approach to storing the package metadata, a=20 combination of SQLite and compressed text files. I am hoping to create a=20 situation where if either gets corrupted it can be created from the other. = =20 =46urther more, any changes to the text files (even without recompressing t= hem)=20 will be intergrated back into the database. This will allow administrators= =20 to fiddle around with the text files without having to touch the database. = =20 (( Another idea I have is the ability for the whole package data storage to be= =20 recreated from the repository data if all stored data got "destroyed". Thi= s=20 will occur though a process of inspection of the file system. This could b= e=20 extended to allow all none package files to be combined into a "special"=20 package with the correct dependencies allowing a system to be restored=20 without a single error... Any thoughts? )) I would also like to create package groupings, where by many packages share= =20 the same package file. This will allow easy distribution of ports such as= =20 the Xorg 7.2, reducing the 400 or so packages to only a few physical files= =20 that can then be installed and managed individually. =20 Ultimately I would like this project to be compatible with the current pkg= =20 system (allowing easy transition from one to another), proper integration=20 into the ports system and possibly into the pkgsrc system, but the future=20 will only be revealed in time. =20 All feedback is welcome, I do have some questions to ask: 1) What would random access of a package be required for and how often=20 will/does it occur?=20 2) I have chosen XML for storing the data. Is there any practical alternat= ive=20 (Please keep in mind that multiple packages metadata could be stored in a=20 single file) I apologies if the document is too dense any too cryptic, all ideas are=20 welcome. =20 Once again thank you all for your feedback and have a good weekend. =20 David --Boundary-01=_nnNRGI9yUkC+3An-- --nextPart1701573.s2DFBrc6Nc Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQBGRNnryqzxLKpyZI8RAkGLAJ4naFsv5FPVpeyLsGa3XfLKu3yT/ACfQfs2 d9w/Fd8sxNbh5XSMAtAlhUM= =6X17 -----END PGP SIGNATURE----- --nextPart1701573.s2DFBrc6Nc--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200705112302.35380.dragonsa>