Not a new distro, goodness no. Just an alternate package management system, which would work something like this: It would be transparent with pacman. On could easily use pacman or it interchangeably, but this would have additional package management 'tools'. Many functions, such as installing a new package, re-installing a package, and package removal would be offloaded onto pacman anyway. The only real difference with this would be when upgrading(and possibly downgrading) a package, and possibly it would have some more robust information about package file information. All scripts, config files, pacbuilds, and such would be maintained by a distributed scm (Mercurial is what I like, but Git could work too). This may have to be customized to more closely fit our purposes, or maybe even re-implemented with as the tasks we would demand of it would not be as great(perhaps). This may also allow for a person to simply reset all config files to their defaults in a very lazy fashion. Binaries would be individually hashed (SHA1?), and then this information would be stored. After being hashed the binaries would be tightly compressed(Bzip2?) as individual files, if the binary does not already have a hash value which matches up with a previous hash of that file(in this case the new file is simply discarded - it did not change). A hash for checking the integrity of the compressed file would also be stored. When a person decides to sync their package information, the data on file differences is what syncs(in addition to the package version info). When the client decides to upgrade a file, the clients computer would check what the different files between the currently installed package and the package on the mirror were. These files would then be what they would request to download. Following downloading these files, they would be extracted to the proper locations (using .pacnew for new config files that exist in the system). A low priority would be for there to be both an old config file backup system and a merge of new config files with old config files function(most likely taken directly from the scm being used). This would not be enforced on the user, but some may like it as an option (opposed to manually hunting down config files that need to be updated). Verbose logging of all operations would be a very high priority. The hashes of the uncompressed binaries would be important, as it would allow for the package management software to determine if binaries have be modified since they were installed. By default I do not think it would care when upgrading, but some people(esp. those with RPM roots) may enjoy this for being able to check for rootkits and file corruption. Downgrading of the system would not be a high priority at all, but it may not be excluded. This system would have a greater dependence on a local internet connection, and thus I would not like to force it upon people. I like pacman a lot, but this is an interesting idea on management(and I have been jealous of Forsight linux's capabilities similar to this. If only it was a lightweight build your own like Arch...) And that is the summery of my current thoughts on this. Any thoughts or willing helpers out there? ~Nekody 林科迪 On 9/18/09, goodmenzy@xxxxxxxxx <goodmenzy@xxxxxxxxx> wrote: > A new distro? evil idea!! > By the way: reinvent the wheel may be an interesting > progress............................................................................. > > > On 2009-09-17 23:10:10, nekomancer davion wrote: >> Date: Thu, 17 Sep 2009 23:10:10 -0400 >> From: nekomancer davion <ladislaio@xxxxxxxxx> >> To: General Discusson about Arch Linux <arch-general@xxxxxxxxxxxxx> >> Subject: Re: [arch-general] An evil idea --- use Git to manage the >> repositories >> Reply-To: General Discusson about Arch Linux <arch-general@xxxxxxxxxxxxx> >> Message-ID: <bd5ae8c50909172010q110ceb4aif005c02f8063c413@xxxxxxxxxxxxxx> >> Content-Type: text/plain; charset=UTF-8 >> Content-Transfer-Encoding: quoted-printable >> List-Id: General Discusson about Arch Linux <arch-general.archlinux.org> >> >> Forsight linux does something like this, but their server side was >> closed source the last time I took a look(back in February). >> http://en.wikipedia.org/wiki/Conary_(package_manager) >> >> It is a very interesting idea, and could speed things up a lot. It >> would make downloading packages to install elsewhere a pain in some >> cases though. Using GIT as-is would be a bad idea(perhaps hack >> mercurial to do the work instead?). >> >> It would be rather non-KISS, but it does not sound too hard so long as >> you do not allow for rollbacks(Just store a list of what files are >> different and thus would need to be updated). >> >> goodmenz if you want to try to hack something together, I should have >> time to assist, although not much(still in school, busy semester). >> Anyone else interested? >> >> Forking mercurial and pacman into MerMan would be the new Linux >> package management system which finally bring about the year of the >> Linux desktop! >> >> ~Nekody >> 林克迪 >> >> On 9/9/09, Caleb Cushing <xenoterracide@xxxxxxxxx> wrote: >> > you are forgetting how quickly and ginormassly huge the git repo's would >> > get. >> > >> > -- >> > Caleb Cushing >> > >> > http://xenoterracide.blogspot.com >> > >
