From owner-freebsd-hackers@FreeBSD.ORG Fri May 11 21:03:42 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0D02516A403 for ; Fri, 11 May 2007 21:03:42 +0000 (UTC) (envelope-from naylor.b.david@gmail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.232]) by mx1.freebsd.org (Postfix) with ESMTP id A288C13C447 for ; Fri, 11 May 2007 21:03:41 +0000 (UTC) (envelope-from naylor.b.david@gmail.com) Received: by wx-out-0506.google.com with SMTP id s18so995040wxc for ; Fri, 11 May 2007 14:03:41 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:from:to:subject:date:user-agent:mime-version:content-type:content-transfer-encoding:message-id:sender; b=DMtl8CxJQy1PNI5UPw6rvFkTzHg19AtkfSilAWKGhjgdzEmMa+MNPuqBSHRSLIorQgEhbpH/JxvlSwQuPViPzGxEakwAND24EMNYNFGY0iJPGWxTud22XTisevq6g2DtxazhqcHvA+ql5q7FpUNtMMeV3cB1LZubJDsgPXVUl+M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:from:to:subject:date:user-agent:mime-version:content-type:content-transfer-encoding:message-id:sender; b=j9q3nLG5qCH34ft4VRy9vIz1pYFQV+5UKJSsBBFbxIAmnT77tPA+NqmIAPBGofc3GI315FeYVSOYdU7eAzaPY3ntThif+vloh+nxRTLFV0dIRKGaWlKynhB8/Q9A1tD5RzxGNwyWYgTQ91BLJVhCTHsTWM8oOhB3UBsg32Gmg0Y= Received: by 10.90.118.12 with SMTP id q12mr3614030agc.1178917421126; Fri, 11 May 2007 14:03:41 -0700 (PDT) Received: from ?0.0.0.0? ( [196.37.90.163]) by mx.google.com with ESMTP id 44sm14801482wri.2007.05.11.14.03.34; Fri, 11 May 2007 14:03:37 -0700 (PDT) From: David Naylor To: freebsd-hackers@freebsd.org Date: Fri, 11 May 2007 23:02:31 +0200 User-Agent: KMail/1.9.5 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1701573.s2DFBrc6Nc"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200705112302.35380.dragonsa@highveldmail.co.za> Sender: David Naylor X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: DPS Initial Ideas X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 May 2007 21:03:42 -0000 --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--