[pacman-dev] [PATCH 1/2] libalpm: introduce a disabled status for repos
Disabled repos are still sync'd on a repo refresh, but will never be
searched in when looking for package upgrades. A user can still opt to
explicitly install something from this repo by using the repo/pkgname
format for a target.
This patch introduces get/set methods for the disabled attribute on the
alpm_db_t object, alpm_db_{get,set}_disabled().
Signed-off-by: Dave Reisner
Hook up a per-repo 'Disabled' flag in the config for users to mark repos
as disabled. This can take a boolean value such as 'yes', 'true', or
'1', or the similar negated 'no', 'false', or '0'.
Signed-off-by: Dave Reisner
On 03/07/12 09:45, Dave Reisner wrote:
Hook up a per-repo 'Disabled' flag in the config for users to mark repos as disabled. This can take a boolean value such as 'yes', 'true', or '1', or the similar negated 'no', 'false', or '0'.
Why do we need this complexity? Why not just specifying "Disabled" disables the repo and not specifying does not...
Signed-off-by: Dave Reisner
--- It's possible that I'm blowing smoke with my strcasecmp commment... doc/pacman.conf.5.txt | 7 +++++++ src/pacman/conf.c | 38 ++++++++++++++++++++++++++++++++++++++ 2 files changed, 45 insertions(+)
diff --git a/doc/pacman.conf.5.txt b/doc/pacman.conf.5.txt index a9c5db3..cc2d88f 100644 --- a/doc/pacman.conf.5.txt +++ b/doc/pacman.conf.5.txt @@ -226,6 +226,13 @@ even be used for different architectures. Set the signature verification level for this repository. For more information, see <
> below. +*Disabled =* boolean:: + Allows a repository to be marked as disabled. Disabled repositories will + not be searched when looking for updates, but will continue to be refreshed. + This option takes a boolean true or false value. True can be the string + ``1'', ``yes'', or ``true'', case insensitive. False can be the string ``0'', + ``no'', or ``false'', case insensitive. + Package and Database Signature Checking --------------------------------------- The 'SigLevel' directive is valid in both the `[options]` and repository diff --git a/src/pacman/conf.c b/src/pacman/conf.c index 4aaacb5..4d042aa 100644 --- a/src/pacman/conf.c +++ b/src/pacman/conf.c @@ -636,6 +636,7 @@ struct section_t { /* db section option gathering */ alpm_siglevel_t siglevel; alpm_list_t *servers; + int disabled; };
/** @@ -669,6 +670,8 @@ static int finish_section(struct section_t *section, int parse_options) goto cleanup; }
+ alpm_db_set_disabled(db, section->disabled); + for(i = section->servers; i; i = alpm_list_next(i)) { char *value = i->data; if(_add_mirror(db, value) != 0) { @@ -687,9 +690,29 @@ cleanup: section->siglevel = ALPM_SIG_USE_DEFAULT; free(section->name); section->name = NULL; + section->disabled = 0; return ret; }
+static int string_to_boolean(const char *string) +{ + /* usage of strcasecmp here is allowed since we're comparing + * against fixed strings */ + if(strcasecmp(string, "1") == 0 || + strcasecmp(string, "true") == 0 || + strcasecmp(string, "yes") == 0) { + return 1; + } + + if(strcasecmp(string, "0") == 0 || + strcasecmp(string, "false") == 0 || + strcasecmp(string, "no") == 0) { + return 0; + } + + return -1; +} + /** The "real" parseconfig. Each "Include" directive will recall this method so * recursion and stack depth are limited to 10 levels. The publicly visible * parseconfig calls this with a NULL section argument so we can recall from @@ -856,6 +879,21 @@ static int _parseconfig(const char *file, struct section_t *section, } FREELIST(values); } + } else if(strcmp(key, "Disabled") == 0) { + if(value == NULL) { + pm_printf(ALPM_LOG_ERROR, _("config file %s, line %d: directive '%s' needs a value\n"), + file, linenum, key); + ret = 1; + goto cleanup; + } + section->disabled = string_to_boolean(value); + if (section->disabled < 0) { + pm_printf(ALPM_LOG_ERROR, _("config file %s, line %d: directive '%s' has " + "invalid boolean value %s\n"), + file, linenum, key, value); + ret = 1; + goto cleanup; + } } else { pm_printf(ALPM_LOG_WARNING, _("config file %s, line %d: directive '%s' in section '%s' not recognized.\n"),
On Tue, Jul 03, 2012 at 10:02:03AM +1000, Allan McRae wrote:
On 03/07/12 09:45, Dave Reisner wrote:
Hook up a per-repo 'Disabled' flag in the config for users to mark repos as disabled. This can take a boolean value such as 'yes', 'true', or '1', or the similar negated 'no', 'false', or '0'.
Why do we need this complexity? Why not just specifying "Disabled" disables the repo and not specifying does not...
We may not. Dan brought up the idea of making this a bit more granular, but I don't have my IRC logs to recall exactly what was mentioned... he can weigh in here.
Signed-off-by: Dave Reisner
--- It's possible that I'm blowing smoke with my strcasecmp commment... doc/pacman.conf.5.txt | 7 +++++++ src/pacman/conf.c | 38 ++++++++++++++++++++++++++++++++++++++ 2 files changed, 45 insertions(+)
diff --git a/doc/pacman.conf.5.txt b/doc/pacman.conf.5.txt index a9c5db3..cc2d88f 100644 --- a/doc/pacman.conf.5.txt +++ b/doc/pacman.conf.5.txt @@ -226,6 +226,13 @@ even be used for different architectures. Set the signature verification level for this repository. For more information, see <
> below. +*Disabled =* boolean:: + Allows a repository to be marked as disabled. Disabled repositories will + not be searched when looking for updates, but will continue to be refreshed. + This option takes a boolean true or false value. True can be the string + ``1'', ``yes'', or ``true'', case insensitive. False can be the string ``0'', + ``no'', or ``false'', case insensitive. + Package and Database Signature Checking --------------------------------------- The 'SigLevel' directive is valid in both the `[options]` and repository diff --git a/src/pacman/conf.c b/src/pacman/conf.c index 4aaacb5..4d042aa 100644 --- a/src/pacman/conf.c +++ b/src/pacman/conf.c @@ -636,6 +636,7 @@ struct section_t { /* db section option gathering */ alpm_siglevel_t siglevel; alpm_list_t *servers; + int disabled; };
/** @@ -669,6 +670,8 @@ static int finish_section(struct section_t *section, int parse_options) goto cleanup; }
+ alpm_db_set_disabled(db, section->disabled); + for(i = section->servers; i; i = alpm_list_next(i)) { char *value = i->data; if(_add_mirror(db, value) != 0) { @@ -687,9 +690,29 @@ cleanup: section->siglevel = ALPM_SIG_USE_DEFAULT; free(section->name); section->name = NULL; + section->disabled = 0; return ret; }
+static int string_to_boolean(const char *string) +{ + /* usage of strcasecmp here is allowed since we're comparing + * against fixed strings */ + if(strcasecmp(string, "1") == 0 || + strcasecmp(string, "true") == 0 || + strcasecmp(string, "yes") == 0) { + return 1; + } + + if(strcasecmp(string, "0") == 0 || + strcasecmp(string, "false") == 0 || + strcasecmp(string, "no") == 0) { + return 0; + } + + return -1; +} + /** The "real" parseconfig. Each "Include" directive will recall this method so * recursion and stack depth are limited to 10 levels. The publicly visible * parseconfig calls this with a NULL section argument so we can recall from @@ -856,6 +879,21 @@ static int _parseconfig(const char *file, struct section_t *section, } FREELIST(values); } + } else if(strcmp(key, "Disabled") == 0) { + if(value == NULL) { + pm_printf(ALPM_LOG_ERROR, _("config file %s, line %d: directive '%s' needs a value\n"), + file, linenum, key); + ret = 1; + goto cleanup; + } + section->disabled = string_to_boolean(value); + if (section->disabled < 0) { + pm_printf(ALPM_LOG_ERROR, _("config file %s, line %d: directive '%s' has " + "invalid boolean value %s\n"), + file, linenum, key, value); + ret = 1; + goto cleanup; + } } else { pm_printf(ALPM_LOG_WARNING, _("config file %s, line %d: directive '%s' in section '%s' not recognized.\n"),
On Mon, Jul 2, 2012 at 7:15 PM, Dave Reisner
On Tue, Jul 03, 2012 at 10:02:03AM +1000, Allan McRae wrote:
On 03/07/12 09:45, Dave Reisner wrote:
Hook up a per-repo 'Disabled' flag in the config for users to mark repos as disabled. This can take a boolean value such as 'yes', 'true', or '1', or the similar negated 'no', 'false', or '0'.
Why do we need this complexity? Why not just specifying "Disabled" disables the repo and not specifying does not...
We may not. Dan brought up the idea of making this a bit more granular, but I don't have my IRC logs to recall exactly what was mentioned... he can weigh in here.
Given that we have no key-only options under repos, I'm leaning against having those be introduced. I've never been a fan of them in the [options] section either. -Dan
On 03/07/12 10:22, Dan McGee wrote:
On Mon, Jul 2, 2012 at 7:15 PM, Dave Reisner
wrote: On Tue, Jul 03, 2012 at 10:02:03AM +1000, Allan McRae wrote:
On 03/07/12 09:45, Dave Reisner wrote:
Hook up a per-repo 'Disabled' flag in the config for users to mark repos as disabled. This can take a boolean value such as 'yes', 'true', or '1', or the similar negated 'no', 'false', or '0'.
Why do we need this complexity? Why not just specifying "Disabled" disables the repo and not specifying does not...
We may not. Dan brought up the idea of making this a bit more granular, but I don't have my IRC logs to recall exactly what was mentioned... he can weigh in here.
Given that we have no key-only options under repos, I'm leaning against having those be introduced. I've never been a fan of them in the [options] section either.
OK. But do we really need all of True/Yes/1 etc. I just find that confusing compared to a single "Disabled" flag. How about: Usage = All (default) Usage = Search Install Update Allan
On Tue, Jul 03, 2012 at 10:50:51AM +1000, Allan McRae wrote:
On 03/07/12 10:22, Dan McGee wrote:
On Mon, Jul 2, 2012 at 7:15 PM, Dave Reisner
wrote: On Tue, Jul 03, 2012 at 10:02:03AM +1000, Allan McRae wrote:
On 03/07/12 09:45, Dave Reisner wrote:
Hook up a per-repo 'Disabled' flag in the config for users to mark repos as disabled. This can take a boolean value such as 'yes', 'true', or '1', or the similar negated 'no', 'false', or '0'.
Why do we need this complexity? Why not just specifying "Disabled" disables the repo and not specifying does not...
We may not. Dan brought up the idea of making this a bit more granular, but I don't have my IRC logs to recall exactly what was mentioned... he can weigh in here.
Given that we have no key-only options under repos, I'm leaning against having those be introduced. I've never been a fan of them in the [options] section either.
OK. But do we really need all of True/Yes/1 etc. I just find that confusing compared to a single "Disabled" flag.
How about: Usage = All (default) Usage = Search Install Update
Allan
I think I like this. /me starts a new branch...
This defines a level of interest a user has in a repository. These are
described by the bitmask flags in the alpm_db_usage_t enum:
ALPM_DB_USAGE_SEARCH: repo is valid for searching
ALPM_DB_USAGE_INSTALL: repo is valid for installs (e.g. -S pkg)
ALPM_DB_USAGE_UPGRADE: repo is valid for sysupgrades
ALPM_DB_USAGE_ALL: all of the above are valid
Explicitly listing the contents of a repo will always be valid, and the
repo will always be refreshed appropriately on sync operations.
Signed-off-by: Dave Reisner
Add a "Usage" key to the repo section of the config which allows for the
tokens "Search", "Install", "Upgrade", "All", which correspond to values
in the alpm_db_usage_t enum. Users can specify "Usage" multiple times
for a given repo, or multiple flags per "Usage" line and they will be
OR'd together. If unspecified, the default is full usage of the repo.
Signed-off-by: Dave Reisner
participants (4)
-
Allan McRae
-
Dan McGee
-
Dave Reisner
-
Dave Reisner