[pacman-dev] repo-add DB entry size

Roman Kyrylych roman.kyrylych at gmail.com
Wed Mar 21 11:15:00 EDT 2007

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?

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

Roman Kyrylych (Роман Кирилич)

More information about the pacman-dev mailing list