This document lists features that might yet be implemented in glpm, the gtk3 front-end to lpm. It is divided into the sections

• important missing features
• important changes
• desirable missing features
• desirable changes
• wishlist

The document is currently based on commit f1cfe59 of the gtk3 branch of dalglish:/var/lib/git/lpm.git.

(Above commit name corresponds to the value retrurn by: git log -1 –pretty=format:%h )

If any change or feature description has the remark (needs core change), the implementation would require a change to liblpm and/or plpm and therefore needs to be coordinated accordingly.

There are currently no recognized important missing features

There are currently no recognized important changes

For locally installed packages as well as package files, it would be nice to be able the not only view the info of the package, but also its data.

The ideal place to do this would be on its package detail popup, where a button called “Contents” would then rertrieve the data and display it in a pop-up or below attached block. like the plpm output block. The contents of of a package is simply a list of fully qualified filename.

To retrieve the list of filenames, the following functions are available:

        /* This is for a local package file */
        if (lpk_file_is_lpk(object_name)) {
            contents = lpm_lpf_index(lpm,object_name);
            if (contents) {
                display_contents(contents);
                for (i=0; contents[i] != NULL;i++) {
                    printf("%s\n",contents[i]);
                }
                arr_free(contents);
            }
        /* And this is for installed packages */
        } else {
            contents = lpm_lpl_index(lpm,object_name);
            if (contents) {
                for (i=0; contents[i] != NULL;i++) {
                    printf("%s\n",contents[i]);
                }
                arr_free(contents);
            }
        }

It is already mentioned under 2.1 that if the user chooses to display not only the newest available packages, but all available versions, he could then choose exactly one package from the list for installation.

In that case, the frontend would have to supply not only the name but also both version and the eventual variant to plpm.

It seems that the current implementation of plpm_execute has not yet implemented that functionality:

    for (GList *lp = packages; lp != NULL; lp = lp->next) {
        LPI *lpi = lp->data;
        g_string_append_c (command, ' ');
        g_string_append (command, lpi->name);
    }

In lpmsh.c, this is handled as follows:

            if (num_pkgs == 1) {
                    if ( (optver != NULL) && ((optvar != NULL) ) ) {
                        sprintf(optstr," -o version=%.100s,variant=%.100s ",optver,optvar);
                    } else if (optver != NULL) {
                        sprintf(optstr," -o version=%.100s ",optver);
                    } else if (optvar != NULL) {
                        sprintf(optstr," -o variant=%.100s ",optvar);
                    }
                    if (strlen(optstr)> 0) {
                        strncat(syscmd,optstr,400);
                    }
                }
                strcat(syscmd,packages[0]);
            } else {
                pkgstr = arr2str(packages,' ');
                strncat(syscmd,pkgstr,1000);
                free(pkgstr);
            }

Therefore, a corresponding plpm_execute implementation would look something like that:

if (number_of_elements_in_packages == 1) {
    GList *lp = packages;
    LPI *lpi = lp->data;
    if (lpi->variant != NULL) {
        sprintf(optstr," -o version=%.100s,variant=%.100s ",lpi->version,lpi->variant);
    } else {
        sprintf(optstr," -o version=%.100s ",lpi->version);
    }
    g_string_append (command,optstr);
    g_string_append (command,lpi->name);
} else {
    for (GList *lp = packages; lp != NULL; lp = lp->next) {
        LPI *lpi = lp->data;
        g_string_append_c (command, ' ');
        g_string_append (command, lpi->name);
    }
}

This code would then also work for a downgrade of package, by just passing the desired lpi wrapped in this GList thing.

A downgrade of a package should take place at the GLPM_PACKAGE_VIEW_MODE_INSTALLED view, either by an option in a package's context menu (right-click), or on the package details window. In any case, to find out if a downgrade is even available, a call to lpm_findpkg_new will return the number of available versions and all the available package definitons:

num_vers = lpm_findpkg(lpm,lpc,lpk_name,variant,NULL,5,NULL,&vers_list);

, whith lpk_name set to lpi→name and variant set to lpi→variant of the selected package.

If num_vers is greater than 0, the user should then somehow be offered to chance to update to one of the versions, apart from the one selected.

Maybe the user interface should not whether a package is newer or older, also lpm does not care itself, it just allows to update to any available specified version. To find that out, the following code is used whithin lpm for that purpose:

#define VERS_NEWER(x) x> 0
#define VERS_OLDER(x) x <0
#define VERS_EQUAL(x) x == 0

res = strverscmp(vers_list[i]->version,sel_lpi->version);
if (VERS_OLDER(res)) {

After the user has decided for an offered version, plpm_execute can then be called with the corresponding package.

After every successfull install, update or delete, lpm writes an entry to the install.log. This file is just a simple text file, but is an good reference what packages have been installed, updated or deleted when, and why.

It would be nice to have an option in the Action menu that would just open a scrollable text window displaying the contents of the file.

There currently is an implementation in glpm_app_view_logfile that dumps the contents in the application's text buffer, but opening a separate window for this would be nicer.

• remove installed pachage (needs core change)
• new LPM logo
• update-only startup
• verify package contents by hash (needs core change)
• group-privileged refresh (needs core changes)
• update-only startup (maybe using notify)
• show dependent packages (on installed packages only)