DSM-G600, DNS-3xx and NSA-220 Hack Forum

puterboy wrote:

Just some thoughts here.

1. Any reason not to include a '-l' (list option)
    Say something trivial like adding:

listpkg()
{
    # checks
    test $# -eq 1       || die "Internal Error: listpkg <pkg-name>"
    test -e "$pkgdb/$1" || die "$1: No such package"

    info "Listing contents of package $1 ..."

    cat $pkgdb/$1
}

How about taking it a step further. Attached is sketch for a more generic utility. It can select packages by name or content. It prints matching packet names, and, if requested, file matches or full package contents.

---

Attachments:
whichpkg, Size: 1,495 bytes, Downloads: 183

fonz wrote:

puterboy wrote:

2. Any reason not to include checking on the upgrade option that newer version is higher (and maybe require a force type argument to upgrade if not) or alternatively use a capital U as the option for including such checking.

I'm not opposed to the general idea, but I think it's better suited for a higher-level tool; one that, e.g. can also access online package repositories.

I assume that you are thinking something like this analogy:
<higher-level tool> : funpkg :: yum/apt/smart : rpm
(i.e. funpkg and rpm are the low level while you are looking towards a new higher level tool)

This is all great and a nice direction.
However, if that is the right analogy, then I would suggest that the two features I mentioned at the start of this thread belong to the lower level tool analogous to where rpm won't downgrade unless you use --force and of course there is the very useful rpm -ql (list) feature.

I guess the way I think about it is that rpm (and rpmbuild in particular) is really the gold-plated model that has way more capabilities than are presently needed for a basic fun_plug installation so it would be foolhardy and a lot of work to try to replicate everything in rpm.

On the other hand, there are some "low hanging fruit" consisting of commonly used and easy to implement features that can be adapted from rpm for use in funpkg with only some brief shell script coding.

Another feature I would add, would be the -q for query to look up package name (and probably would use some of the functionality you sketch out in your attachment). Actually that could then be combined with the -l that I suggested above and used analogously to the usage in rpm.

Basically, there are probably a handful of short functions that could be added to funpkg to cover probably about 80-90% of the common usage of rpm (not the rpmbuild part but the rpm query/install/upgrade/erase/verify functionality).

Since many of us probably are used to rpm, a nice parallel usage could be very helpful and also later serve as a building block for higher level repository functionality or just build-your-own shell scripts.

smart is a higher level package manager that some people prefer to yum. I personally have never tried it.

fonz wrote:

With your version logic in place, they would have to deal with the downgraded package separately. Instead of 'upgrading to the latest version in ffp', they would have to 'force a downgrade'. That's not convincing.

True. I guess the makers of rpm believe that a downgrade is the exception rather than the rule and that users are more likely to do it by mistake than intentionally -- hence, the need to "force" a downgrade.

Personally, it's not a big issue for me.

fonz wrote:

The recommended method for users is to download the changed packages (e.g. using rsync -av --delete ...)

How does "rsync --delete" work here where different package versions have different tar file names and thus appear as distinct files to rsync? Wouldn't you still need some type of versioning script to erase the "older" packages with "lower" version numbers.

It's not a big deal to me, because once I get everything set up neatly (which is why I am pushing in the other thread to have something like fun_plug-base be treated as a real package), then I will just write some simple scripts that will automatically look at my current list of packages, use rsync to download newer versions to the directory where I store the tar files, do an upgrade on all the new ones, and then remove the obsoleted older tarfiles (or perhaps keep a user-specifiable number of older versions).

I just like investing a bit more up front to ensure that I have a reliable and consistent process for maintaining and upgrading my system that at the same time guarantees me the latest version but also prevents me from having clutter accumulate from old orphaned packages.

Once I write it, I will be happy to share it with the group.