On 2/26/07, Jason Chu wrote:

...

Where does 'replaces' info belong? I leave the question open, because i have no opinion, but I'd like to do this right - where does it fit best? The /depends file seems more appropriate, as it contains all the "list" info already.

+1

I vote for depends as well. Aren't conflicts and provides already there too? It seems to fit perfectly with those. I also say we should try to put it consistently in depends, including in the repos. We may need to have a rather extended transition period where it is in both, however, as we should try to be backwards compatible with what pacman2 expects for a while. -Dan

On 2/26/07, Aaron Griffin wrote:

On 2/26/07, Dan McGee wrote:

...

I vote for depends as well. Aren't conflicts and provides already there too? It seems to fit perfectly with those. I also say we should try to put it consistently in depends, including in the repos. We may need to have a rather extended transition period where it is in both, however, as we should try to be backwards compatible with what pacman2 expects for a while.

Well, the argument for using /desc is that it's already read in the case of a sysupgrade, making it quicker to load using the files backend.

But shouldn't we be reading conflicts and provides anyway in the case of a sysupgrade? -Dan

On 2/26/07, Aaron Griffin wrote:

On 2/26/07, Dan McGee wrote:

...

I vote for depends as well. Aren't conflicts and provides already there too? It seems to fit perfectly with those. I also say we should try to put it consistently in depends, including in the repos. We may need to have a rather extended transition period where it is in both, however, as we should try to be backwards compatible with what pacman2 expects for a while.

Well, the argument for using /desc is that it's already read in the case of a sysupgrade, making it quicker to load using the files backend.

Currently, repo-add writes to the /depends file, it seems. This should be a fairly quick change to fix this up. For 'replaces' info, we will just have to read BOTH desc and depends files for now. I could always issue a warning when replaces info is found in the /desc file, saying it's an old repo and should be updated before this is unsupported... just a suggestion.

Just actually looked at the code (a novel idea)- repo-add writes replaces info to ./desc, which is the same behavior as pacman 2. Why don't we assume this behavior for now (no point in changing it if it may just get changed again), and go from there. If we want to do a DB format change, that is a whole different issue. -Dan

On 2/28/07, Aaron Griffin wrote:

On 2/28/07, Dan McGee wrote:

...

repo-add writes replaces info to ./desc

Hmm, I thought it was the other way around. Sticking with that until we revamp the backend is probably a good idea.

We should make sure we remove all the code that expects provides entries in the /depends file though, and make sure that doesn't break any pactests.

PS I got nothing done last night, I fell asleep watching Stargate, so heh.

I just made local changes to try to make everything consistant. I want to run pactest first obviously before I commit. I also commented out lines in pactest so it makes things as identical to repo-add as possible. Sleep is a good thing. :) -Dan

On 2/26/07, Jason Chu wrote:

...

...

Where does 'replaces' info belong? I leave the question open, because i have no opinion, but I'd like to do this right - where does it fit best? The /depends file seems more appropriate, as it contains all the "list" info already.

+1

I vote for depends as well. Aren't conflicts and provides already there too? It seems to fit perfectly with those. I also say we should try to put it consistently in depends, including in the repos. We may need to have a rather extended transition period where it is in both, however, as we should try to be backwards compatible with what pacman2 expects for a while.

I think depends sounds like the right place too, for what it is worth. I do have a related question though. Why are there two files with the package info? Just wanting to know the reasoning behind the choice, to split the desc and depends info into separate files, instead of a single file to parse?

I've thought about that too... actually, i've been wanting to try an architecture where we don't have: /var/lib/pacman/*/foo-1.2-1/desc but /var/lib/pacman/*/foo-1.2-1 as a normal file, containing all info. Less files == good.

Still, part of the reason the pacman3 DB format hasn't changed much is for easy of transition. I don't feel comfortable saying "run this script to convert your DB" or something like that.... so basically it needs to be thought out well in advance.

I think that is a reasonable position though. I think holding to backwards compatibility in *some cases*, will only maintain previous limitations. I think the major version change (pacman 3.x) is a good indicator to end users that things like this are expected to change.

On 2/26/07, Travis Willard wrote:

No need to make them run a script - the difference in DB format is obvious enough for pacman3, on first run, to detect the 'old' format based on the db structure, output a message like

==> pacman has detected an older version of the database, and must update it. This will happen only once, please wait...

and do the conversion automatically on first run.

Yeah, but that adds complexity in the fact that pacman must have code to read the old format, and the new... and how long do we maintain this format? It'd have to be there until all repos switch the format (and they'd have to be converted each -Sy operation until then) AND a new iso with pacman3 is created. It's totally doable, but, like I said, it needs to be thought out in advance. brain0 brought up a configurable backend at one point. i.e. pacman.conf:DbBackend = files I would actually prefer some sort of method like this if we go through and actually change the DB. It'd be rather simple to do something like "echo files >> /var/lib/pacman/local/.dbformat" and simply maintain read/write routines for each backend (be_files.c already has a setup very close to what would be needed, though adding more than one into the library would require some extra code). This way, we could do something like this: read config, see "backend = sqlite", check .dbformat, see "files", do a conversion. If no .dbformat is specified, assume "files"... etc etc Rather straightforward, and it allows the end user a choice as to what DB format they use... The REAL question here is, should the pacman 3.0 release be delayed for something like this, or should we hold of until 3.1?

On 2/26/07, Aaron Griffin wrote:

On 2/26/07, Travis Willard wrote: The REAL question here is, should the pacman 3.0 release be delayed for something like this, or should we hold of until 3.1?

Although it feels good to do a release (and I'm sure its presence would be appreciated on the 0.8 ISO's, although we all know this really isn't as big of a deal as people make it out to be), should we just instead get pacman into the form we will be happy with for a major version number release? We can mark something soon in CVS as "stable", and if people are really looking for an upgrade, then they can go there. We could even through it in the unstable repo if demand was high. Just putting my two cents out there, be interesting to see what other people think about postponing release. -Dan

On Mon, 26 Feb 2007 09:36:58 -0800 (PST) eliott@cactuswax.net wrote:

I say choose a single backend. Modify it as needed, but keep the backend choice simple. Ie... one backend.

+1 While user-selectable backend would be keen, it's fluff that I don't see as necessary to pacman's greater function. One relatively quick and functional backend would probably make everybody's life easier. -- Travis

On Mon, 26 Feb 2007 10:08:51 -0800 Jason Chu wrote:

[jchu@wingnut pacman-2.9.8-4]$ cat /var/lib/pacman/local/pacman-2.9.8-4/install

... post_upgrade() { if [ ! -d var/lib/pacman/local ]; then echo "==> Converting database..." >&2 mkdir -p var/lib/pacman/local && usr/bin/convertdb var/lib/pacman/local echo "==> Done." >&2 fi ...

Not trying to argue for changing the db format now, just mentioning that it's been done before and the references still exist.

Damn, that's... just too simple. XD Experience ftw. -- Travis