[pacman-dev] repo-add DB entry size
dpmcgee at gmail.com
Wed Mar 21 11:21:45 EDT 2007
On 3/21/07, Roman Kyrylych <roman.kyrylych at gmail.com> wrote:
> 2007/3/21, Dan McGee <dpmcgee at gmail.com>:
> > On 3/21/07, Roman Kyrylych <roman.kyrylych at gmail.com> wrote:
> > > IMHO %PACKAGER% can be removed (it's in .PKGINFO anyway).
> > > Same for %ARCH% and %URL%.
> > >
> > > %LICENSE% is not usefull yet, but it will be when Aaron's (IIRC)
> > > proposal for license-dependent installs will be implemented.
> > >
> > > %BUILDDATE% can be used for version comparison instead of
> > > pkgver+pkgrel (this will effectively eliminate issues like "which is
> > > newer 2.1 or 2.1a?" !!!), but we will have to use W3C's datetime
> > > format.
> > > Otherwise it's unneeded too (it's in .PKGINFO anyway).
> > Of course I know all of this is in .PKGINFO. :) But .PKGINFO is not
> > available until after download and extraction. Personally, I like
> > having everything available, because we can then offer a lot more
> > information up in the -Si screen.
> > I think FILENAME and ARCH make sense, because this could in the future
> > allow for one base repo DB, and pacman would intelligently choose
> > correct packages based on the ARCH entry in the DB.
> > URL is something I really think should be there. You can get to it
> > from archlinux.org package search, why not from your own computer? If
> > I do a package search and it comes up with something I'm unfamiliar
> > with, I should be able to take a look at it's URL to see what its
> > about.
> > I like your thinking on BUILDDATE, but the devil is in the details.
> > Not sure why I didn't put all this in my original email, but oh well.
> My bad. You're right about -Si. Then I think we don't have the choice
> and should leave everything as it is now. :-P Did you compare sizes of
> extra.db.tar.gz generated with pacman2 and pacman3? Is increase in
> size very noticeable in compressed files' sizes?
I'll have to give this a try on gerolde, obviously not on the live DB. :)
> About %BUILDDATE% - IMHO it's not hard to implement with W3C's
> datetime format (just simple string compare), we should just be sure
> that "newer build" always means "newer package" (I guess it is, but I
> may miss something).
Yeah, we have this BR/FR: <http://bugs.archlinux.org/task/6468>
It is something on both Aaron's and I's TODO list, so this should make
it into 3.1.
More information about the pacman-dev