[pacman-dev] package PKGINFO format vs DB format
I may be missing some history here, but I am wondering why the package metadata is in a different format than the DB metadata. As far as parsing goes, it would be ideal to unify the two formats. Does anyone (judd, you're CC'd on this) know any reason to keep two different formats, or any tools that would be negatively impacted by such a change? Please note, a "negative impact" is not that same as "we have to change it for the new format" - more along the lines of "we can no longer do XYZ". -- Aaron
2007/4/23, Aaron Griffin <aaronmgriffin@gmail.com>:
I may be missing some history here, but I am wondering why the package metadata is in a different format than the DB metadata.
As far as parsing goes, it would be ideal to unify the two formats.
Does anyone (judd, you're CC'd on this) know any reason to keep two different formats, or any tools that would be negatively impacted by such a change? Please note, a "negative impact" is not that same as "we have to change it for the new format" - more along the lines of "we can no longer do XYZ".
Status? I don't know any reason to keep them different. -- Roman Kyrylych (Роман Кирилич)
On 5/17/07, Roman Kyrylych <roman.kyrylych@gmail.com> wrote:
2007/4/23, Aaron Griffin <aaronmgriffin@gmail.com>:
I may be missing some history here, but I am wondering why the package metadata is in a different format than the DB metadata.
As far as parsing goes, it would be ideal to unify the two formats.
Does anyone (judd, you're CC'd on this) know any reason to keep two different formats, or any tools that would be negatively impacted by such a change? Please note, a "negative impact" is not that same as "we have to change it for the new format" - more along the lines of "we can no longer do XYZ".
Status? I don't know any reason to keep them different.
-- Roman Kyrylych (Роман Кирилич) _______________________________________________ pacman-dev mailing list pacman-dev@archlinux.org http://archlinux.org/mailman/listinfo/pacman-dev
This died a LONG way back. But I have something relevant here, courtesy of Chantry: http://www.archlinux.org/pipermail/pacman-dev/2006-March/005702.html I'm all in favor of doing this, although it is going to break some things. We will need to plan a transition roadmap, especially if we want to get the local DB in the same format. -Dan
2007/6/26, Dan McGee <dpmcgee@gmail.com>:
On 5/17/07, Roman Kyrylych <roman.kyrylych@gmail.com> wrote:
2007/4/23, Aaron Griffin <aaronmgriffin@gmail.com>:
I may be missing some history here, but I am wondering why the package metadata is in a different format than the DB metadata.
As far as parsing goes, it would be ideal to unify the two formats.
Does anyone (judd, you're CC'd on this) know any reason to keep two different formats, or any tools that would be negatively impacted by such a change? Please note, a "negative impact" is not that same as "we have to change it for the new format" - more along the lines of "we can no longer do XYZ".
Status? I don't know any reason to keep them different.
This died a LONG way back. But I have something relevant here, courtesy of Chantry: http://www.archlinux.org/pipermail/pacman-dev/2006-March/005702.html
I'm all in favor of doing this, although it is going to break some things. We will need to plan a transition roadmap, especially if we want to get the local DB in the same format.
+10 for that new format! (IIRC it was mentioned at least once after that date too) I see two possibilities: 1) leave the current code for handling directory-based database during the transition period, 2) modify it to do a conversion to a new format when unpacking .db.tar.gz or finding existing unpacked database in old format. .db.tar.gz could be kept in current format for a while, to allow people who upgrade rarely to avoid problem. Or we can start using new format quickly, but leave pacman/{desc,depends} in a db, which will be parsed by old pacman, but not a new one. This will allow users to upgrade pacman first, then all other updates can be fetched by a new pacman. -- Roman Kyrylych (Роман Кирилич)
On 6/26/07, Dan McGee <dpmcgee@gmail.com> wrote:
On 5/17/07, Roman Kyrylych <roman.kyrylych@gmail.com> wrote:
2007/4/23, Aaron Griffin <aaronmgriffin@gmail.com>:
I may be missing some history here, but I am wondering why the package metadata is in a different format than the DB metadata.
As far as parsing goes, it would be ideal to unify the two formats.
Does anyone (judd, you're CC'd on this) know any reason to keep two different formats, or any tools that would be negatively impacted by such a change? Please note, a "negative impact" is not that same as "we have to change it for the new format" - more along the lines of "we can no longer do XYZ".
Status? I don't know any reason to keep them different.
-- Roman Kyrylych (Роман Кирилич) _______________________________________________ pacman-dev mailing list pacman-dev@archlinux.org http://archlinux.org/mailman/listinfo/pacman-dev
This died a LONG way back. But I have something relevant here, courtesy of Chantry: http://www.archlinux.org/pipermail/pacman-dev/2006-March/005702.html
I'm all in favor of doing this, although it is going to break some things. We will need to plan a transition roadmap, especially if we want to get the local DB in the same format.
And it died again it seems! This is a lot of work, and I'm trying to keep on top of these things.... So here's the operative question to get the ball rolling. Which format do we like more? [ foo = bar baz = blah ] vs [ %FOO% bar %BAZ% blah ] And try not to think about where/when bash and python and things like that need this data - that's a non-issue as we can always write helper utils using libalpm's parsing if it becomes really hard for things like, say, namcap.
2007/9/19, Aaron Griffin <aaronmgriffin@gmail.com>:
Which format do we like more?
[ foo = bar baz = blah ] vs [ %FOO% bar
%BAZ% blah ]
And try not to think about where/when bash and python and things like that need this data - that's a non-issue as we can always write helper utils using libalpm's parsing if it becomes really hard for things like, say, namcap.
+1 for the first format. I looks better IMO + it i s easier to work with bash, sed, grep etc. -- Roman Kyrylych (Роман Кирилич)
On 9/19/07, Roman Kyrylych <roman.kyrylych@gmail.com> wrote:
2007/9/19, Aaron Griffin <aaronmgriffin@gmail.com>:
Which format do we like more?
[ foo = bar baz = blah ] vs [ %FOO% bar
%BAZ% blah ]
And try not to think about where/when bash and python and things like that need this data - that's a non-issue as we can always write helper utils using libalpm's parsing if it becomes really hard for things like, say, namcap.
+1 for the first format. I looks better IMO + it i s easier to work with bash, sed, grep etc.
-- Roman Kyrylych (Роман Кирилич)
First seems easier on the eyes for sure. And not very hard to parse. :P -Dan
On Wed, Sep 19, 2007 at 12:49:12AM -0500, Aaron Griffin wrote:
And it died again it seems!
This is a lot of work, and I'm trying to keep on top of these things....
So here's the operative question to get the ball rolling.
Which format do we like more?
[ foo = bar baz = blah ] vs [ %FOO% bar
%BAZ% blah ]
And try not to think about where/when bash and python and things like that need this data - that's a non-issue as we can always write helper utils using libalpm's parsing if it becomes really hard for things like, say, namcap.
Which files exactly are we talking about? What about "files" (no pun intended ;) in the local db?
On 9/19/07, Xavier <shiningxc@gmail.com> wrote:
On Wed, Sep 19, 2007 at 12:49:12AM -0500, Aaron Griffin wrote:
And it died again it seems!
This is a lot of work, and I'm trying to keep on top of these things....
So here's the operative question to get the ball rolling.
Which format do we like more?
[ foo = bar baz = blah ] vs [ %FOO% bar
%BAZ% blah ]
And try not to think about where/when bash and python and things like that need this data - that's a non-issue as we can always write helper utils using libalpm's parsing if it becomes really hard for things like, say, namcap.
Which files exactly are we talking about? What about "files" (no pun intended ;) in the local db?
Lemme see if I recall correctly. The second format is obviously our current DB format. The first is the .PKGINFO file in the package tarballs themselves. I, also, like the first format better. Here's on thing that wasn't brought up above - list parsing: [ list = one list = two list = three ] vs [ %LIST% one two three ]
2007/9/19, Aaron Griffin <aaronmgriffin@gmail.com>:
Which files exactly are we talking about? What about "files" (no pun intended ;) in the local db?
Lemme see if I recall correctly. The second format is obviously our current DB format. The first is the .PKGINFO file in the package tarballs themselves.
I, also, like the first format better.
Here's on thing that wasn't brought up above - list parsing:
[ list = one list = two list = three ] vs [ %LIST% one two three ]
Sure we do understand that there's also list parsing. And still the first format is better :P -- Roman Kyrylych (Роман Кирилич)
On Wed, Sep 19, 2007 at 12:49:12AM -0500, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
[ foo = bar baz = blah ]
then %FOO% bar baz would become foo = bar baz ? won't it result in *very* long lines for the filelists? - VMiklos
On 9/19/07, Miklos Vajna <vmiklos@frugalware.org> wrote:
On Wed, Sep 19, 2007 at 12:49:12AM -0500, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
[ foo = bar baz = blah ]
then
%FOO% bar baz
would become
foo = bar baz
?
won't it result in *very* long lines for the filelists?
Well actually, the current format just repeats. So it'd be: foo = bar foo = baz In a way it makes sense, because, this is a DB entry really... you wouldn't be resetting the variable. But as a programmer it *does* read a little funny.
On Wed, Sep 19, 2007 at 01:25:40PM -0500, Aaron Griffin wrote:
On 9/19/07, Miklos Vajna <vmiklos@frugalware.org> wrote:
On Wed, Sep 19, 2007 at 12:49:12AM -0500, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
[ foo = bar baz = blah ]
then
%FOO% bar baz
would become
foo = bar baz
?
won't it result in *very* long lines for the filelists?
Well actually, the current format just repeats. So it'd be:
foo = bar foo = baz
In a way it makes sense, because, this is a DB entry really... you wouldn't be resetting the variable. But as a programmer it *does* read a little funny.
I think it'll look rather odd, especially for the big file lists. files = usr/share/locale/fr/ files = usr/share/locale/fr/LC_MESSAGES/ files = usr/share/locale/fr/LC_MESSAGES/libalpm.mo files = usr/share/locale/fr/LC_MESSAGES/pacman.mo files = usr/share/locale/hu/ files = usr/share/locale/hu/LC_MESSAGES/ files = usr/share/locale/hu/LC_MESSAGES/libalpm.mo files = usr/share/locale/hu/LC_MESSAGES/pacman.mo files = usr/share/locale/it/ files = usr/share/locale/it/LC_MESSAGES/ files = usr/share/locale/it/LC_MESSAGES/libalpm.mo files = usr/share/locale/it/LC_MESSAGES/pacman.mo files = usr/share/locale/pl_PL/ files = usr/share/locale/pl_PL/LC_MESSAGES/ files = usr/share/locale/pl_PL/LC_MESSAGES/libalpm.mo files = usr/share/locale/pl_PL/LC_MESSAGES/pacman.mo files = usr/share/locale/pt_BR/ files = usr/share/locale/pt_BR/LC_MESSAGES/ files = usr/share/locale/pt_BR/LC_MESSAGES/libalpm.mo files = usr/share/locale/pt_BR/LC_MESSAGES/pacman.mo files = usr/share/locale/ru_RU/ files = usr/share/locale/ru_RU/LC_MESSAGES/ files = usr/share/locale/ru_RU/LC_MESSAGES/libalpm.mo files = usr/share/locale/ru_RU/LC_MESSAGES/pacman.mo But maybe it isn't that bad after all. The second inconvenient is the additional space used. On the other hand, it'll be much easier to work with using grep, like Romashka already mentioned. With : files = usr/share/locale/ru_RU/LC_MESSAGES/libalpm.mo files = usr/share/locale/ru_RU/LC_MESSAGES/pacman.mo ... backup = etc/pacman.conf c176542c3e4c13044e57ba65e47f3e69 backup = etc/makepkg.conf 318712d2c8ee9196f395b60ceb13fe35 ... Then I could just grep backup /var/lib/pacman/local/*/files to see all the backup entries. I wanted to do that because of the little bug in pacman 3.1 that only filled the first md5sum, to check which packages are affected in my db :)
On 9/19/07, Xavier <shiningxc@gmail.com> wrote:
On Wed, Sep 19, 2007 at 01:25:40PM -0500, Aaron Griffin wrote:
On 9/19/07, Miklos Vajna <vmiklos@frugalware.org> wrote:
On Wed, Sep 19, 2007 at 12:49:12AM -0500, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
[ foo = bar baz = blah ]
then
%FOO% bar baz
would become
foo = bar baz
?
won't it result in *very* long lines for the filelists?
Well actually, the current format just repeats. So it'd be:
foo = bar foo = baz
In a way it makes sense, because, this is a DB entry really... you wouldn't be resetting the variable. But as a programmer it *does* read a little funny.
I think it'll look rather odd, especially for the big file lists.
files = usr/share/locale/fr/ files = usr/share/locale/fr/LC_MESSAGES/ files = usr/share/locale/fr/LC_MESSAGES/libalpm.mo files = usr/share/locale/fr/LC_MESSAGES/pacman.mo files = usr/share/locale/hu/ files = usr/share/locale/hu/LC_MESSAGES/ files = usr/share/locale/hu/LC_MESSAGES/libalpm.mo files = usr/share/locale/hu/LC_MESSAGES/pacman.mo files = usr/share/locale/it/ files = usr/share/locale/it/LC_MESSAGES/ files = usr/share/locale/it/LC_MESSAGES/libalpm.mo files = usr/share/locale/it/LC_MESSAGES/pacman.mo files = usr/share/locale/pl_PL/ files = usr/share/locale/pl_PL/LC_MESSAGES/ files = usr/share/locale/pl_PL/LC_MESSAGES/libalpm.mo files = usr/share/locale/pl_PL/LC_MESSAGES/pacman.mo files = usr/share/locale/pt_BR/ files = usr/share/locale/pt_BR/LC_MESSAGES/ files = usr/share/locale/pt_BR/LC_MESSAGES/libalpm.mo files = usr/share/locale/pt_BR/LC_MESSAGES/pacman.mo files = usr/share/locale/ru_RU/ files = usr/share/locale/ru_RU/LC_MESSAGES/ files = usr/share/locale/ru_RU/LC_MESSAGES/libalpm.mo files = usr/share/locale/ru_RU/LC_MESSAGES/pacman.mo
But maybe it isn't that bad after all. The second inconvenient is the additional space used.
On the other hand, it'll be much easier to work with using grep, like Romashka already mentioned.
With : files = usr/share/locale/ru_RU/LC_MESSAGES/libalpm.mo files = usr/share/locale/ru_RU/LC_MESSAGES/pacman.mo ... backup = etc/pacman.conf c176542c3e4c13044e57ba65e47f3e69 backup = etc/makepkg.conf 318712d2c8ee9196f395b60ceb13fe35 ...
Then I could just grep backup /var/lib/pacman/local/*/files to see all the backup entries.
I wanted to do that because of the little bug in pacman 3.1 that only filled the first md5sum, to check which packages are affected in my db :)
Yeah, and even more so, if we then move everything to one file instead of three (speculating here, not saying it's a good idea), grep becomes infinitely more useful. grep files /var/lib/pacman/local/foo-1.0-1
participants (5)
-
Aaron Griffin
-
Dan McGee
-
Miklos Vajna
-
Roman Kyrylych
-
Xavier