[pacman-dev] repo-add DB entry size
I've noticed that our sync DB entries got a lot bigger with the new repository generation tools. Are we sure we want this? Here is a DB entry produced by repo-add: $ cat custom/pacman-3.0.0-rc2/desc %FILENAME% pacman-3.0.0-rc2-i686.pkg.tar.gz %NAME% pacman %VERSION% 3.0.0-rc2 %DESC% A library-based package manager with dependency support %CSIZE% 791331 %ISIZE% 2014429 %MD5SUM% 263805fff1ce59550f37a22dac468a31 %URL% http://www.archlinux.org/pacman/ %LICENSE% GPL %ARCH% i686 %BUILDDATE% Mon Mar 12 18:05:54 2007 %PACKAGER% Dan McGee <dpmcgee@gmail.com> %REPLACES% pacman-rc And a DB entry from pacman 2 tools: $ cat current/pacman-2.9.8-4/desc %NAME% pacman %VERSION% 2.9.8-4 %DESC% A .tar.gz based package manager with dependency support %CSIZE% 488015 %MD5SUM% c6e0ffd2fd0f8e69f9ba0cb9de8fcf64 We have 13 vs. 5 fields in the old. I don't know if this will be a significant slowdown for pacman, but it will definitely be larger DB downloads once you do this to every package in current or extra. -Dan
2007/3/21, Dan McGee <dpmcgee@gmail.com>:
I've noticed that our sync DB entries got a lot bigger with the new repository generation tools. Are we sure we want this?
Here is a DB entry produced by repo-add: $ cat custom/pacman-3.0.0-rc2/desc %FILENAME% pacman-3.0.0-rc2-i686.pkg.tar.gz
%NAME% pacman
%VERSION% 3.0.0-rc2
%DESC% A library-based package manager with dependency support
%CSIZE% 791331
%ISIZE% 2014429
%MD5SUM% 263805fff1ce59550f37a22dac468a31
%URL% http://www.archlinux.org/pacman/
%LICENSE% GPL
%ARCH% i686
%BUILDDATE% Mon Mar 12 18:05:54 2007
%PACKAGER% Dan McGee <dpmcgee@gmail.com>
%REPLACES% pacman-rc
And a DB entry from pacman 2 tools: $ cat current/pacman-2.9.8-4/desc %NAME% pacman
%VERSION% 2.9.8-4
%DESC% A .tar.gz based package manager with dependency support
%CSIZE% 488015
%MD5SUM% c6e0ffd2fd0f8e69f9ba0cb9de8fcf64
We have 13 vs. 5 fields in the old. I don't know if this will be a significant slowdown for pacman, but it will definitely be larger DB downloads once you do this to every package in current or extra.
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). -- Roman Kyrylych (Роман Кирилич)
On 3/21/07, Roman Kyrylych <roman.kyrylych@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. -Dan
2007/3/21, Dan McGee <dpmcgee@gmail.com>:
On 3/21/07, Roman Kyrylych <roman.kyrylych@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 (Роман Кирилич)
On 3/21/07, Roman Kyrylych <roman.kyrylych@gmail.com> wrote:
2007/3/21, Dan McGee <dpmcgee@gmail.com>:
On 3/21/07, Roman Kyrylych <roman.kyrylych@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. -Dan
participants (2)
-
Dan McGee
-
Roman Kyrylych