Re: An evil idea --- use Git to manage the repositories

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]



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
>> >
>


[Index of Archives]     [Linux Wireless]     [Linux Kernel]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Share Photos]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Device Mapper]
  Powered by Linux