[Slapt-get-devel] slapt-get "source priority" patches

Jason Woodward woodwardj at jaos.org
Sun Nov 23 14:56:23 EST 2008


Hi Ken,

> The attached patches are my attempt at implementing "source priority" 
> support for slapt-get, which can be useful for keeping your system 
> closely in step with an online repository (such as the official 
> Slackware release and patches).
> 
> I implemented this feature after noticing that slapt-get occasionally 
> ignores an official Slackware patch, because it considers the version 
> number to be a "downgrade" from the installed package.
> 
> With the patches applied, it is possible to nominate certain mirrors 
> from which packages will always be installed, regardless of version 
> number.  Each mirror can be assigned a priority level, and the mirror 
> with the highest priority is always chosen to download a package.  But 
> I've tried to make things sufficiently flexible that it is possible to 
> keep your core system in line with the official patches, while still 
> upgrading ancilliary packages based on version numbers.
> 
> Two patches are included, against the CVS versions of slapt-get and 
> gslapt.  The slapt-get patch includes some documentation, with an 
> example config file.  The gslapt patch provides basic support for the 
> new feature, but could do with further work to allow display and editing 
> of the mirror priorities.
> 
> I hope this is of use to somebody.  Be warned that it has received 
> minimal testing, and there are probably hideous bugs or other drawbacks 
> that I haven't thought of.  Use at your own risk!  Any comments or 
> suggestions are welcome.

This is great.  I have a couple of questions/suggestions:

> +      PRIORITY=source_priority[,patch_priority]
> +
> +    For example:
> +
> +      PRIORITY=0     # source priority 0, patch priority 0 (the default)
> +      PRIORITY=1     # source priority 1, patch priority 1
> +      PRIORITY=1,2   # source priority 1, patch priority 2
> +
> +    The priority number affects all subsequent SOURCE directives in the
> +    slapt-getrc file, and is interpreted as follows:
> +
> +    - PRIORITY=0 is the default.  It gives the usual slapt-get behaviour,
> +      whereby packages are upgraded based on their version numbers.
> +
> +      A package from a source with priority 0 will upgrade the installed
> +      package only if the package from the source has a higher version number.
> +
> +    - PRIORITY=1 or more allows the packages from a mirror to be tracked
> +      more closely.
> +
> +      A package from a source with priority 1 or more will "upgrade" the
> +      installed package whenever the version strings differ, regardless of
> +      whether this is an upgrade or a downgrade in terms of version number
> +      comparison.
> +
> +      Where a package is available in different versions from several different
> +      sources, the package from the source with the greatest priority number
> +      will be used for upgrade.  Version numbers are only considered in the
> +      event of a tie between two packages from sources with the same priority.
> +
> +    - Specifying a separate patch priority allows the packages from the /patches
> +      directory on a mirror to be given a higher priority than those on the rest
> +      of the mirror.  This is particularly useful for tracking official
> +      Slackware patches.

I'm hesitant to add the extra token to the configuration.  I think maybe
:[attribute1],[attribute2]... after the SOURCE entry may be a better way to do it.  That way
parsing is easier, the association between the priority and the source is less confusing, and
rewriting the configuration file from gslapt is less error prone.  If we add comma delimited
attributes after the source I think it solves all of the above concerns.

We should prefer a name rather than a number as it is more clear what the intent is, like:
OFFICIAL, PREFERRED, CUSTOM (maybe a better name for this).  The default needs no token/value.

Something like:

typedef enum {
    SLAPT_PRIORITY_DEFAULT = 0,
    SLAPT_PRIORITY_DEFAULT_PATCH,
    SLAPT_PRIORITY_PREFERRED,
    SLAPT_PRIORITY_PREFERRED_PATCH,
    SLAPT_PRIORITY_OFFICIAL,
    SLAPT_PRIORITY_OFFICIAL_PATCH,
    SLAPT_PRIORITY_CUSTOM,
    SLAPT_PRIORITY_CUSTOM_PATCH
} SLAPT_PRIORITY_T;

/* call as SLAPT_SET_PRIORITY(OFFICIAL) */
#define SLAPT_SET_PRIORITY(p) SLAPT_PRIORITY_ ## p


> +# A local package repository at priority 3.
> +# This might contain packages which the user has customised and wants to
> +# override those in the official release.
> +PRIORITY=3
> +SOURCE=file:///pub/packages/

collapse into SOURCE=file:///pub/packages:CUSTOM

> +# The official Slackware packages at priority 1, with patches at priority 2.
> +# The higher patch priority ensures that patch packages will always replace
> +# those from the initial release, even if this means regressing to a lower
> +# version number.
> +PRIORITY=1,2
> +SOURCE=ftp://ftp.slackware.com/pub/slackware/slackware-12.1/

collapse into SOURCE=ftp://ftp.slackware.com/pub/slackware/slackware-12.1/:OFFICIAL

> +# An unofficial package mirror at priority 0.
> +# Packages will be upgraded from this mirror whenever a higher version number
> +# becomes available, but only when this is not overridden by a package from one
> +# of the higher priority sources above.
> +PRIORITY=0
> +SOURCE=http://darkstar.ist.utl.pt/slackware/addon/slacky/slackware-12.1/

This should just stay the same.


>  struct slapt_source_list {
>    char **url;
>    unsigned int count;
> +  int *source_priority;
> +  int *patch_priority;
>  };

We should probably just create a source structure to store the priority information with the
url string.

slapt_add_source() should just take in the struct rather than the string.  Might as well update
the api to keep it clean since we are changing a few struct definitions.

Same with slapt_cmp_pkg().

> +          p->priority = global_config->sources->patch_priority[i];

This should probably always be global_config->sources[i]->patch_priority (which is just
priority + 1 as defined in the above enumeration).  No need to keep separate lists.



>        1,global_config->sources->url[i],
>        2,TRUE,
> +      3,priority_str,
>        -1);

Yeah, the interface for gslapt will be a bit more difficult.  We may have to redo the source
add interface so that we present another model dialog for inputing the URI along with
additional options.


Overall this is a great idea and implementation.  If the source configuration syntax is tweaked
as discussed above and the api is updated then this is ready to be merged.


take care,
jason
--
Jason Woodward
woodwardj at jaos.org




More information about the Slapt-get-devel mailing list