[pacman-dev] 'replaces' confusion
So it appears the backend and pactest are both a little confused about where 'replaces' belongs. If we look at a current repo, 'replaces' is listed in the /desc file: $ cat /var/lib/pacman/current/gawk-3.1.5-3/desc %NAME% gawk %VERSION% 3.1.5-3 %DESC% Gnu version of awk %CSIZE% 552398 %MD5SUM% 4f539bb7ba6bb3328a2891ecf4ad2caf %REPLACES% mawk However, it appears that libalpm actually *writes* this info to the /depends file - replaces info is NOT written to the local DB. Please note that it appears this code is never actually hit. The db_write routine is not currently used when unpacking a remote DB, it is mostly untarred directly. In the future, however, this routine WILL be used to write DB info, so it is important to figure this out now: 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. Anyone have an opinion?
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 Jason
On 2/26/07, Jason Chu <jason@archlinux.org> 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, Dan McGee <dpmcgee@gmail.com> 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.
On 2/26/07, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
On 2/26/07, Dan McGee <dpmcgee@gmail.com> 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, Dan McGee <dpmcgee@gmail.com> wrote:
But shouldn't we be reading conflicts and provides anyway in the case of a sysupgrade?
Yeah, but those are both *after* the package is elected for upgrade... that is, the set of packages has been significantly reduced. I'm not saying this makes it worthwhile, really, just pointing it out.
On 2/26/07, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
On 2/26/07, Dan McGee <dpmcgee@gmail.com> 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, Dan McGee <dpmcgee@gmail.com> 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.
On 2/28/07, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
On 2/28/07, Dan McGee <dpmcgee@gmail.com> 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/28/07, Dan McGee <dpmcgee@gmail.com> wrote:
On 2/28/07, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
On 2/28/07, Dan McGee <dpmcgee@gmail.com> 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.
Local changes have been pushed to CVS. I don't think I broke anything, pactest gave me the same results as before. :) Currently failing tests: sync895 upgrade051 (this is expected, won't fix until post-3.0) upgrade055 upgrade056 -Dan
On 2/26/07, Jason Chu <jason@archlinux.org> 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?
On 2/26/07, eliott@cactuswax.net <eliott@cactuswax.net> wrote:
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'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 Mon, 26 Feb 2007 10:37:46 -0600 "Aaron Griffin" <aaronmgriffin@gmail.com> wrote:
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.
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. Just my two cents. :) -- Travis
On 2/26/07, Travis Willard <travisw@wmpub.ca> 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 <aaronmgriffin@gmail.com> wrote:
brain0 brought up a configurable backend at one point. i.e. pacman.conf:DbBackend = files
Just to add additional complexity to the conversation, this could even be added to a DB section (Server = ) to maintain totally different backends for each DB... i.e. local could be "sqlite", extra could be "bdb", current could be "single-file", etc etc. /me muses I'm going to the gym now, gonna think about this there.
On 2/26/07, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
On 2/26/07, Travis Willard <travisw@wmpub.ca> 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
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?
Such a change like that (new backends) would illicit a major version increment I would think. Nothing says there must be a huge lag from pacman 3.x to pacman 4.x. ;) In regard to the backend talk. I think the number of possible backends should be very limited. Think of it from a supportability standpoint. With people using different backends, when something happens with one users pacman install, it would be much harder to pin down the issue. More backends means less users running the same basic configuration, harder to support, etc. I say choose a single backend. Modify it as needed, but keep the backend choice simple. Ie... one backend.
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
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.
Let us go back to days of yor. Once upon a time, pacman's db format looked different than it does today. [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.
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?
As nice as it sounds, I think top priority is getting 3.0 out. I vote to not delay it. Jason
On Mon, 26 Feb 2007 10:08:51 -0800 Jason Chu <jason@archlinux.org> 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
* On Monday, February 26 2007, Jason Chu wrote:
As nice as it sounds, I think top priority is getting 3.0 out. I vote to not delay it.
Agreed, let's not delay this release. On a side note, 3.1 seems like a great place to have this conversion :) // codemac -- .: [ + carpe diem totus tuus + ] :.
participants (6)
-
Aaron Griffin
-
Dan McGee
-
eliott＠cactuswax.net
-
Jason Chu
-
Jeff 'codemac' Mickey
-
Travis Willard