[pacman-dev] [PATCH 00/13] Files database operations
This patchset adds support for reading the .files database and performing the following: - downloading/updating the .files database - checking which package contains a file - searching for a file (including regex support) - listing all files from a package Allan McRae (13): Simplify sync_cleandb Fix formatting in parsearg_upgrade Add files option to handle libalpm: handle both .db and .files extensions Read file lists from files database Add pacman support for .files databases pacman: move database syncing to util.c Prototype pacman files database operations Implement locating file owner in sync files database Implement listing files from sync packages Implement searching for a file in the sync databases Add regex search option to sync database file searching Handle repo/pkg style arguments to sync repo file listing lib/libalpm/alpm.h | 3 + lib/libalpm/be_sync.c | 61 +++++++++-- lib/libalpm/db.c | 10 +- lib/libalpm/handle.c | 13 +++ lib/libalpm/handle.h | 1 + src/pacman/Makefile.am | 1 + src/pacman/callback.c | 2 +- src/pacman/conf.c | 4 + src/pacman/conf.h | 6 +- src/pacman/files.c | 271 +++++++++++++++++++++++++++++++++++++++++++++++++ src/pacman/pacman.c | 88 +++++++++++++++- src/pacman/pacman.h | 2 + src/pacman/sync.c | 84 ++++----------- src/pacman/util.c | 33 ++++++ src/pacman/util.h | 1 + 15 files changed, 498 insertions(+), 82 deletions(-) create mode 100644 src/pacman/files.c -- 2.4.4
1) Remove checks for removing pre-tardb files
2) Remove the long redundant keep_used parameter
3) Fix pacman error due to removing .sig file along with database
Signed-off-by: Allan McRae
Signed-off-by: Allan McRae
This option will be used to determine if the .files database should be used
for reading sync information.
Signed-off-by: Allan McRae
Reads from the .db or .files database depending on the flags in the handle.
Signed-off-by: Allan McRae
Signed-off-by: Allan McRae
Signed-off-by: Allan McRae
Signed-off-by: Allan McRae
Add the -F/--files operations, -s/--sync support and nd provide dummy
functions for -s/--search, -l/-list and -o/--owns.
Signed-off-by: Allan McRae
Equivalent to -Qo but for packages in the sync database
e.g. pacman -Fo /usr/bin/pacman
Signed-off-by: Allan McRae
Does the equivalent of the -Ql option for local packages
e.g. pacman -Fl glibc
Signed-off-by: Allan McRae
Locates all packages that contain the listed file
e.g. pacman -Fs libpng.so
Signed-off-by: Allan McRae
e.g. pacman -Fsx kcm.*print.*\.so
Signed-off-by: Allan McRae
Passing "-Fl pkg" will print the filelist for the first occurance of "pkg"
in the sync repos. Other version of the package can be printed using
"-Fl repo/pkg".
Signed-off-by: Allan McRae
On 20/06/15 17:42, Allan McRae wrote:
This patchset adds support for reading the .files database and performing the following: - downloading/updating the .files database - checking which package contains a file - searching for a file (including regex support) - listing all files from a package
I will do documentation at some stage...
On 06/20/15 at 05:42pm, Allan McRae wrote:
This option will be used to determine if the .files database should be used for reading sync information.
Signed-off-by: Allan McRae
--- lib/libalpm/alpm.h | 3 +++ lib/libalpm/handle.c | 13 +++++++++++++ lib/libalpm/handle.h | 1 + 3 files changed, 17 insertions(+) diff --git a/lib/libalpm/alpm.h b/lib/libalpm/alpm.h index 06e080b..b6b9175 100644 --- a/lib/libalpm/alpm.h +++ b/lib/libalpm/alpm.h @@ -859,6 +859,9 @@ int alpm_option_set_deltaratio(alpm_handle_t *handle, double ratio); int alpm_option_get_checkspace(alpm_handle_t *handle); int alpm_option_set_checkspace(alpm_handle_t *handle, int checkspace);
+int alpm_option_get_files(alpm_handle_t *handle); +int alpm_option_set_files(alpm_handle_t *handle, int files);
Can we use a more descriptive option name? If I didn't already know what it does, the name "files" wouldn't give me much of a clue. apg
On 06/20/15 at 05:42pm, Allan McRae wrote:
Reads from the .db or .files database depending on the flags in the handle.
Signed-off-by: Allan McRae
--- lib/libalpm/be_sync.c | 23 +++++++++++++++++------ lib/libalpm/db.c | 10 ++++++++-- 2 files changed, 25 insertions(+), 8 deletions(-)
I don't really like hard-coding a distinction between normal db's and file db's in alpm. We already have to teach alpm to handle multiple db extensions, so we could just make the extension configurable and allow the front-end to do the selection. That way alpm would simply use whatever it's given and treat all sync db's the same. With proper front-end support, which could easily be added later, this would allow a distribution to choose to provide only a files db in order to prevent the primary and files db's from getting out of sync. In order to reduce unnecessary overhead, the files option could be retained solely to indicate whether or not to actually load the files from syncdb's or we could lazy load them as we do for local packages, although we would probably want to load all file lists from a given db at once. apg
diff --git a/lib/libalpm/be_sync.c b/lib/libalpm/be_sync.c index ea979e6..2214edf 100644 --- a/lib/libalpm/be_sync.c +++ b/lib/libalpm/be_sync.c @@ -174,6 +174,7 @@ valid: int SYMEXPORT alpm_db_update(int force, alpm_db_t *db) { char *syncpath; + const char *db_suffix = NULL; alpm_list_t *i; int ret = -1; mode_t oldmask; @@ -208,6 +209,13 @@ int SYMEXPORT alpm_db_update(int force, alpm_db_t *db) RET_ERR(handle, ALPM_ERR_HANDLE_LOCK, -1); }
+ /* determine db suffix */ + if(handle->files == 0) { + db_suffix = ".db"; + } else { + db_suffix = ".files"; + } + for(i = db->servers; i; i = i->next) { const char *server = i->data, *final_db_url = NULL; struct dload_payload payload; @@ -220,10 +228,11 @@ int SYMEXPORT alpm_db_update(int force, alpm_db_t *db) payload.max_size = 25 * 1024 * 1024;
/* print server + filename into a buffer */ - len = strlen(server) + strlen(db->treename) + 5; + len = strlen(server) + strlen(db->treename) + strlen(db_suffix) + 2; /* TODO fix leak syncpath and umask unset */ MALLOC(payload.fileurl, len, RET_ERR(handle, ALPM_ERR_MEMORY, -1)); - snprintf(payload.fileurl, len, "%s/%s.db", server, db->treename); + snprintf(payload.fileurl, len, "%s/%s%s", server, db->treename, db_suffix); + payload.handle = handle; payload.force = force; payload.unlink_on_fail = 1; @@ -244,7 +253,9 @@ int SYMEXPORT alpm_db_update(int force, alpm_db_t *db)
/* check if the final URL from internal downloader looks reasonable */ if(final_db_url != NULL) { - if(strlen(final_db_url) < 3 || strcmp(final_db_url + strlen(final_db_url) - 3, ".db") != 0) { + if(strlen(final_db_url) < 3 || + strcmp(final_db_url + strlen(final_db_url) - strlen(db_suffix), + db_suffix) != 0) { final_db_url = NULL; } } @@ -254,8 +265,8 @@ int SYMEXPORT alpm_db_update(int force, alpm_db_t *db) /* print final_db_url into a buffer (leave space for .sig) */ len = strlen(final_db_url) + 5; } else { - /* print server + filename into a buffer (leave space for separator and .db.sig) */ - len = strlen(server) + strlen(db->treename) + 9; + /* print server + filename into a buffer (leave space for separator and .sig) */ + len = strlen(server) + 1 + strlen(db->treename) + strlen(db_suffix) + 5; }
/* TODO fix leak syncpath and umask unset */ @@ -264,7 +275,7 @@ int SYMEXPORT alpm_db_update(int force, alpm_db_t *db) if(final_db_url != NULL) { snprintf(payload.fileurl, len, "%s.sig", final_db_url); } else { - snprintf(payload.fileurl, len, "%s/%s.db.sig", server, db->treename); + snprintf(payload.fileurl, len, "%s/%s%s.sig", server, db->treename, db_suffix); }
payload.handle = handle; diff --git a/lib/libalpm/db.c b/lib/libalpm/db.c index fe208be..7c79e1c 100644 --- a/lib/libalpm/db.c +++ b/lib/libalpm/db.c @@ -375,10 +375,16 @@ const char *_alpm_db_path(alpm_db_t *db) CALLOC(db->_path, 1, pathsize, RET_ERR(db->handle, ALPM_ERR_MEMORY, NULL)); sprintf(db->_path, "%s%s/", dbpath, db->treename); } else { - pathsize = strlen(dbpath) + 5 + strlen(db->treename) + 4; + const char *suffix; + if(db->handle->files == 0) { + suffix = ".db"; + } else { + suffix = ".files"; + } + pathsize = strlen(dbpath) + 5 + strlen(db->treename) + strlen(suffix) + 1; CALLOC(db->_path, 1, pathsize, RET_ERR(db->handle, ALPM_ERR_MEMORY, NULL)); /* all sync DBs now reside in the sync/ subdir of the dbpath */ - sprintf(db->_path, "%ssync/%s.db", dbpath, db->treename); + sprintf(db->_path, "%ssync/%s%s", dbpath, db->treename, suffix); } _alpm_log(db->handle, ALPM_LOG_DEBUG, "database path for tree %s set to %s\n", db->treename, db->_path); -- 2.4.4
On 20/06/15 23:29, Andrew Gregory wrote:
On 06/20/15 at 05:42pm, Allan McRae wrote:
Reads from the .db or .files database depending on the flags in the handle.
Signed-off-by: Allan McRae
--- lib/libalpm/be_sync.c | 23 +++++++++++++++++------ lib/libalpm/db.c | 10 ++++++++-- 2 files changed, 25 insertions(+), 8 deletions(-) I don't really like hard-coding a distinction between normal db's and file db's in alpm. We already have to teach alpm to handle multiple db extensions, so we could just make the extension configurable and allow the front-end to do the selection. That way alpm would simply use whatever it's given and treat all sync db's the same.
How is that different from what is implemented here? handle->files (rename pending...) is set by the front-end and that determines what database is used.
With proper front-end support, which could easily be added later, this would allow a distribution to choose to provide only a files db in order to prevent the primary and files db's from getting out of sync.
This could be added in about three lines now... Add a config option and have it set handle->files as appropriate. I don't understand what you are suggesting here. A
Hi, On 20.06.2015 09:42, Allan McRae wrote:
1) Remove checks for removing pre-tardb files 2) Remove the long redundant keep_used parameter 3) Fix pacman error due to removing .sig file along with database
Signed-off-by: Allan McRae
--- src/pacman/sync.c | 43 ++++++++++++------------------------------- 1 file changed, 12 insertions(+), 31 deletions(-) diff --git a/src/pacman/sync.c b/src/pacman/sync.c index 0c3151e..c42c38d 100644 --- a/src/pacman/sync.c +++ b/src/pacman/sync.c @@ -53,7 +53,7 @@ static int unlink_verbose(const char *pathname, int ignore_missing)
/* if keep_used != 0, then the db files which match an used syncdb * will be kept */ -static int sync_cleandb(const char *dbpath, int keep_used) +static int sync_cleandb(const char *dbpath)
You probably want to remove the comment above this, too.
{ DIR *dir; struct dirent *ent; @@ -77,18 +77,11 @@ static int sync_cleandb(const char *dbpath, int keep_used) const char *dname = ent->d_name; char *dbname; size_t len; + alpm_list_t *i;
if(strcmp(dname, ".") == 0 || strcmp(dname, "..") == 0) { continue; } - /* skip the local and sync directories */ - if(strcmp(dname, "sync") == 0 || strcmp(dname, "local") == 0) { - continue; - } - /* skip the db.lck file */ - if(strcmp(dname, "db.lck") == 0) { - continue; - }
/* build the full path */ snprintf(path, PATH_MAX, "%s%s", dbpath, dname); @@ -116,24 +109,16 @@ static int sync_cleandb(const char *dbpath, int keep_used) continue; }
- if(keep_used) { - alpm_list_t *i; - for(i = syncdbs; i && !found; i = alpm_list_next(i)) { - alpm_db_t *db = i->data; - found = !strcmp(dbname, alpm_db_get_name(db)); - } + for(i = syncdbs; i && !found; i = alpm_list_next(i)) { + alpm_db_t *db = i->data; + found = !strcmp(dbname, alpm_db_get_name(db)); }
- /* We have a database that doesn't match any syncdb. */ + /* We have a file that doesn't match any syncdb. */ if(!found) { - /* ENOENT check is because the signature and database could come in any - * order in our readdir() call, so either file may already be gone. */ - snprintf(path, PATH_MAX, "%s%s.db", dbpath, dbname); - ret += unlink_verbose(path, 1); - /* unlink a signature file if present too */ - snprintf(path, PATH_MAX, "%s%s.db.sig", dbpath, dbname); - ret += unlink_verbose(path, 1); + ret += unlink_verbose(path, 0); } + free(dbname); } closedir(dir); @@ -143,7 +128,7 @@ static int sync_cleandb(const char *dbpath, int keep_used) static int sync_cleandb_all(void) { const char *dbpath; - char *newdbpath; + char *syncdbpath; int ret = 0;
dbpath = alpm_option_get_dbpath(config->handle); @@ -152,17 +137,13 @@ static int sync_cleandb_all(void) return 0; } printf(_("removing unused sync repositories...\n")); - /* The sync dbs were previously put in dbpath/ but are now in dbpath/sync/. - * We will clean everything in dbpath/ except local/, sync/ and db.lck, and - * only the unused sync dbs in dbpath/sync/ */ - ret += sync_cleandb(dbpath, 0);
- if(asprintf(&newdbpath, "%s%s", dbpath, "sync/") < 0) { + if(asprintf(&syncdbpath, "%s%s", dbpath, "sync/") < 0) { ret += 1; return ret; } - ret += sync_cleandb(newdbpath, 1); - free(newdbpath); + ret += sync_cleandb(syncdbpath); + free(syncdbpath);
return ret; }
-- regards, brainpower
On 21/06/15 02:27, brainpower wrote:
/* if keep_used != 0, then the db files which match an used syncdb
* will be kept */ -static int sync_cleandb(const char *dbpath, int keep_used) +static int sync_cleandb(const char *dbpath) You probably want to remove the comment above this, too.
Good catch! Fixed on my branch. A
On 20/06/15 23:29, Andrew Gregory wrote:
On 06/20/15 at 05:42pm, Allan McRae wrote:
Reads from the .db or .files database depending on the flags in the handle.
Signed-off-by: Allan McRae
--- lib/libalpm/be_sync.c | 23 +++++++++++++++++------ lib/libalpm/db.c | 10 ++++++++-- 2 files changed, 25 insertions(+), 8 deletions(-) I don't really like hard-coding a distinction between normal db's and file db's in alpm. We already have to teach alpm to handle multiple db extensions, so we could just make the extension configurable and allow the front-end to do the selection. That way alpm would simply use whatever it's given and treat all sync db's the same. With proper front-end support, which could easily be added later, this would allow a distribution to choose to provide only a files db in order to prevent the primary and files db's from getting out of sync.
In order to reduce unnecessary overhead, the files option could be retained solely to indicate whether or not to actually load the files from syncdb's or we could lazy load them as we do for local packages, although we would probably want to load all file lists from a given db at once.
While not being entirely sure what you envision here, I have just sent through some changes that hopefully addresses some of this... I now have added an enum with the different database types, this is what is stored in the handle, and a function to convert these to a string. Adding a new database extension (e.g. the .source databases I am slowly working on), will be a few lines (excluding code to parse them). I have not added support for configuring database extensions, or for lazy loading files. These can be readily added if a frontend ever wants them, and I think development time is best spent elsewhere without direct interest in that feature. Allan
On 06/23/15 at 11:03pm, Allan McRae wrote:
On 20/06/15 23:29, Andrew Gregory wrote:
On 06/20/15 at 05:42pm, Allan McRae wrote:
Reads from the .db or .files database depending on the flags in the handle.
Signed-off-by: Allan McRae
--- lib/libalpm/be_sync.c | 23 +++++++++++++++++------ lib/libalpm/db.c | 10 ++++++++-- 2 files changed, 25 insertions(+), 8 deletions(-) I don't really like hard-coding a distinction between normal db's and file db's in alpm. We already have to teach alpm to handle multiple db extensions, so we could just make the extension configurable and allow the front-end to do the selection. That way alpm would simply use whatever it's given and treat all sync db's the same. With proper front-end support, which could easily be added later, this would allow a distribution to choose to provide only a files db in order to prevent the primary and files db's from getting out of sync.
In order to reduce unnecessary overhead, the files option could be retained solely to indicate whether or not to actually load the files from syncdb's or we could lazy load them as we do for local packages, although we would probably want to load all file lists from a given db at once.
While not being entirely sure what you envision here, I have just sent through some changes that hopefully addresses some of this...
I now have added an enum with the different database types, this is what is stored in the handle, and a function to convert these to a string. Adding a new database extension (e.g. the .source databases I am slowly working on), will be a few lines (excluding code to parse them).
I have not added support for configuring database extensions, or for lazy loading files. These can be readily added if a frontend ever wants them, and I think development time is best spent elsewhere without direct interest in that feature.
Allan
The point I was trying to make, and clearly did a poor job of, is just that I generally prefer to keep logic in the front-end wherever that can be easily done. The less we hard-code in the back-end, the more flexibility front-ends have. What I envision in this case is to allow front-ends to specify the db extension. So front-ends would simply call something like `alpm_option_set_syncdb_extension(".files")` instead of `alpm_option_set_dbtype`. libalpm would then simply load the sync databases normally using whatever extension was specified and load the files data if the db happens to include it. I'm not sure how you intend to implement the source db's, so having front-ends set the extension may not make sense in light of that. apg
On 24/06/15 02:04, Andrew Gregory wrote:
On 06/23/15 at 11:03pm, Allan McRae wrote:
On 20/06/15 23:29, Andrew Gregory wrote:
On 06/20/15 at 05:42pm, Allan McRae wrote:
Reads from the .db or .files database depending on the flags in the handle.
Signed-off-by: Allan McRae
--- lib/libalpm/be_sync.c | 23 +++++++++++++++++------ lib/libalpm/db.c | 10 ++++++++-- 2 files changed, 25 insertions(+), 8 deletions(-) I don't really like hard-coding a distinction between normal db's and file db's in alpm. We already have to teach alpm to handle multiple db extensions, so we could just make the extension configurable and allow the front-end to do the selection. That way alpm would simply use whatever it's given and treat all sync db's the same. With proper front-end support, which could easily be added later, this would allow a distribution to choose to provide only a files db in order to prevent the primary and files db's from getting out of sync.
In order to reduce unnecessary overhead, the files option could be retained solely to indicate whether or not to actually load the files from syncdb's or we could lazy load them as we do for local packages, although we would probably want to load all file lists from a given db at once.
While not being entirely sure what you envision here, I have just sent through some changes that hopefully addresses some of this...
I now have added an enum with the different database types, this is what is stored in the handle, and a function to convert these to a string. Adding a new database extension (e.g. the .source databases I am slowly working on), will be a few lines (excluding code to parse them).
I have not added support for configuring database extensions, or for lazy loading files. These can be readily added if a frontend ever wants them, and I think development time is best spent elsewhere without direct interest in that feature.
Allan
The point I was trying to make, and clearly did a poor job of, is just that I generally prefer to keep logic in the front-end wherever that can be easily done. The less we hard-code in the back-end, the more flexibility front-ends have. What I envision in this case is to allow front-ends to specify the db extension. So front-ends would simply call something like `alpm_option_set_syncdb_extension(".files")` instead of `alpm_option_set_dbtype`. libalpm would then simply load the sync databases normally using whatever extension was specified and load the files data if the db happens to include it.
I'm not sure how you intend to implement the source db's, so having front-ends set the extension may not make sense in light of that.
It will be a db ending in .source, and probably require a be_source to parse it given the architecture specific depends etc. When that happens, the extensions will have meaning. We will not be able to just throw a db at makepkg and parse it as if it is a sync db. What I am not understanding is why there is a need for the frontend to be able to set the extension rather than the type? I am all for flexibility when there is a defined need. In this case, repo-add only creates db with the ".db" extension - with the equivilant .files db made at the same time. Allan
On 06/24/15 at 09:08am, Allan McRae wrote:
On 24/06/15 02:04, Andrew Gregory wrote:
On 06/23/15 at 11:03pm, Allan McRae wrote:
On 20/06/15 23:29, Andrew Gregory wrote:
On 06/20/15 at 05:42pm, Allan McRae wrote:
Reads from the .db or .files database depending on the flags in the handle.
Signed-off-by: Allan McRae
--- lib/libalpm/be_sync.c | 23 +++++++++++++++++------ lib/libalpm/db.c | 10 ++++++++-- 2 files changed, 25 insertions(+), 8 deletions(-)
<snip>
The point I was trying to make, and clearly did a poor job of, is just that I generally prefer to keep logic in the front-end wherever that can be easily done. The less we hard-code in the back-end, the more flexibility front-ends have. What I envision in this case is to allow front-ends to specify the db extension. So front-ends would simply call something like `alpm_option_set_syncdb_extension(".files")` instead of `alpm_option_set_dbtype`. libalpm would then simply load the sync databases normally using whatever extension was specified and load the files data if the db happens to include it.
I'm not sure how you intend to implement the source db's, so having front-ends set the extension may not make sense in light of that.
It will be a db ending in .source, and probably require a be_source to parse it given the architecture specific depends etc.
Will the source db's just be normal sync db's with additional information for building from source or do you intend them to be something different altogether? If they're just sync db's with extra source information it could still be conditionally loaded when present the same way file information is even if it does require more complex parsing. If they aren't going to have the standard sync db information, I'm curious what alpm will do when syncing a package from a source db. Once a front-end selects source db's will it be an all-or-nothing situation where only source packages can be used, including any dependencies that get brought in?
When that happens, the extensions will have meaning. We will not be able to just throw a db at makepkg and parse it as if it is a sync db.
If we are going to give the db extension real meaning, then I agree that having front-ends just select the type and letting libalpm figure out the extension is the way to go.
What I am not understanding is why there is a need for the frontend to be able to set the extension rather than the type? I am all for flexibility when there is a defined need. In this case, repo-add only creates db with the ".db" extension - with the equivilant .files db made at the same time.
Part of the point of providing extra flexibility where we can is so that front-ends can handle situations that we don't think of. I'm only suggesting this alternative because, as it stands now, this seems to me like a case where we can provide that extra flexibility at *zero* cost to either the back-end or front-end implementations. If it's going to complicate future development though, it's not worth it. Also keep in mind that just because repo-add is the officially provided tool for managing repositories doesn't mean it's the only one. There is another problem that stems from the selection being global, but would be somewhat alleviated by allowing file information to be parsed from normal .db files. As it stands now front-ends cannot load file information for repos that have it while falling back to a standard db otherwise. This would be particularly hard on GUI front-ends which would have to switch back and forth between normal and file db's in order to provide file information to users while still allowing the use of the repos lacking a files db. apg
On 24/06/15 11:24, Andrew Gregory wrote:
On 06/24/15 at 09:08am, Allan McRae wrote:
On 24/06/15 02:04, Andrew Gregory wrote:
On 06/23/15 at 11:03pm, Allan McRae wrote:
On 20/06/15 23:29, Andrew Gregory wrote:
On 06/20/15 at 05:42pm, Allan McRae wrote:
Reads from the .db or .files database depending on the flags in the handle.
Signed-off-by: Allan McRae
--- lib/libalpm/be_sync.c | 23 +++++++++++++++++------ lib/libalpm/db.c | 10 ++++++++-- 2 files changed, 25 insertions(+), 8 deletions(-) <snip>
The point I was trying to make, and clearly did a poor job of, is just that I generally prefer to keep logic in the front-end wherever that can be easily done. The less we hard-code in the back-end, the more flexibility front-ends have. What I envision in this case is to allow front-ends to specify the db extension. So front-ends would simply call something like `alpm_option_set_syncdb_extension(".files")` instead of `alpm_option_set_dbtype`. libalpm would then simply load the sync databases normally using whatever extension was specified and load the files data if the db happens to include it.
I'm not sure how you intend to implement the source db's, so having front-ends set the extension may not make sense in light of that.
It will be a db ending in .source, and probably require a be_source to parse it given the architecture specific depends etc.
Will the source db's just be normal sync db's with additional information for building from source or do you intend them to be something different altogether? If they're just sync db's with extra source information it could still be conditionally loaded when present the same way file information is even if it does require more complex parsing.
For source repos, I just want to get it to the ABS replacement stage. pacman -B glibc would download an extract glibc-x.xx.src.tar.gz and dump it in /var/build (configurable). Then the user would run makepkg.
If they aren't going to have the standard sync db information, I'm curious what alpm will do when syncing a package from a source db.
I suppose having separate source repos for every architecture would mean no architecture specific fields... and be_sync could be used. Hrm... But still handling a source package will be very different than a
Once a front-end selects source db's will it be an all-or-nothing situation where only source packages can be used, including any dependencies that get brought in?
This is currently the case. You register the sync db with alpm_register_syncdb. To change between dbs we need to unregister the db and register a new one.
When that happens, the extensions will have meaning. We will not be able to just throw a db at makepkg and parse it as if it is a sync db.
If we are going to give the db extension real meaning, then I agree that having front-ends just select the type and letting libalpm figure out the extension is the way to go.
What I am not understanding is why there is a need for the frontend to be able to set the extension rather than the type? I am all for flexibility when there is a defined need. In this case, repo-add only creates db with the ".db" extension - with the equivilant .files db made at the same time.
Part of the point of providing extra flexibility where we can is so that front-ends can handle situations that we don't think of. I'm only suggesting this alternative because, as it stands now, this seems to me like a case where we can provide that extra flexibility at *zero* cost to either the back-end or front-end implementations. If it's going to complicate future development though, it's not worth it.
There is cost due to alpm_register_syncdb(). I suppose that changing the extension could release the syncdbs and laod the new one.
Also keep in mind that just because repo-add is the officially provided tool for managing repositories doesn't mean it's the only one.
The filenaming is documented in the repo-add man page. If other tools are not following the example of repo-add, they are doing it wrong...
There is another problem that stems from the selection being global, but would be somewhat alleviated by allowing file information to be parsed from normal .db files. As it stands now front-ends cannot load file information for repos that have it while falling back to a standard db otherwise. This would be particularly hard on GUI front-ends which would have to switch back and forth between normal and file db's in order to provide file information to users while still allowing the use of the repos lacking a files db.
repo-add now unconditionally creates the .files db. So all repos should provide it (assumption I know...). I should check what happens if a repo does not provide the .files db... I am more than happy to make adjustments to the alpm backend to help GUI developers, but I would require actual GUI developers to post here with what they need. I am not programming for a potential need, when there are actual needs going unaddressed. If you happen to be writing a GUI, then there is a need! Allan
participants (3)
-
Allan McRae
-
Andrew Gregory
-
brainpower