tpkg/client

tpkg client code

tpkg - Application Packaging and Deployment

tpkg is a tool for packaging and deploying applications. It is designed to work alongside your operating system's packaging tool.

The packaging features of tpkg work in a similar fashion as many OS packaging tools like rpm, dpkg, SysV, etc, but with some additional features. tpkg is designed to be cross-platform so that you can use the same tool across all the operating systems in your environment.

The deployment features in tpkg are designed to scale to deployments across hundreds or thousands of systems.

Documentation

http://tpkg.github.com/

Help

If you run into any problems or have any questions you'll find us on the tpkg-users mailing list:

https://lists.sourceforge.net/lists/listinfo/tpkg-users

Contributing

1. Fork it
2. Create your feature branch (git checkout -b my-new-feature)
3. Commit your changes (git commit -am 'Added some feature')
4. Push to the branch (git push origin my-new-feature)
5. Create new Pull Request

License

MIT

Credits

Various parties have contributed to tpkg development and hold the copyright to the code they have contributed, including but not limited to:

Yellowpages.com Jason Heiss

client's Issues

metadata HashWithIndifferentAccess incompatible with rails4

The issue I came across has to do with the way rails4 casts parameters to ActionController::Parameters objects. There are some methods rails expects to exist on these objects, but the are missing if the tpkg gem is loaded

Easiest way to repro this would be to run a rails4 app that has tpkg in the Gemfile default group, then execute these steps from the rails console

$raw_parameters = { :teams => { :number => "37" } }
$parameters = ActionController::Parameters.new(raw_parameters)
$parameters.require(:teams).permit!

NoMethodError: undefined method `permitted=' for {"number"=>"37"}:ActiveSupport::HashWithIndifferentAccess
    from /Users/jmcallister/.rvm/gems/ruby-2.1.2@ypleads-sales-tool/gems/actionpack-4.1.4/lib/action_controller/metal/strong_parameters.rb:325:in `block in dup'
    from /Users/jmcallister/.rvm/gems/ruby-2.1.2@ypleads-sales-tool/gems/actionpack-4.1.4/lib/action_controller/metal/strong_parameters.rb:324:in `tap'
    from /Users/jmcallister/.rvm/gems/ruby-2.1.2@ypleads-sales-tool/gems/actionpack-4.1.4/lib/action_controller/metal/strong_parameters.rb:324:in `dup'
    from /Users/jmcallister/.rvm/gems/ruby-2.1.2@ypleads-sales-tool/gems/activesupport-4.1.4/lib/active_support/hash_with_indifferent_access.rb:50:in `with_indifferent_access'

from /Users/jmcallister/.rvm/gems/ruby-2.1.2@ypleads-sales-tool/gems/tpkg-2.3.3/lib/tpkg/metadata.rb:135:in `convert_value'
    from /Users/jmcallister/.rvm/gems/ruby-2.1.2@ypleads-sales-tool/gems/tpkg-2.3.3/lib/tpkg/metadata.rb:51:in `[]='

    from /Users/jmcallister/.rvm/gems/ruby-2.1.2@ypleads-sales-tool/gems/actionpack-4.1.4/lib/action_controller/metal/strong_parameters.rb:337:in `convert_hashes_to_parameters'
    from /Users/jmcallister/.rvm/gems/ruby-2.1.2@ypleads-sales-tool/gems/actionpack-4.1.4/lib/action_controller/metal/strong_parameters.rb:282:in `[]'
    from /Users/jmcallister/.rvm/gems/ruby-2.1.2@ypleads-sales-tool/gems/tpkg-2.3.3/lib/tpkg/metadata.rb:36:in `default'

The output should be

=> {"number"=>"37"}

Now the tpkg gem should not get loaded with rails. It is / was getting loaded b/c it is / was part of the default group in bundler in our application. We no longer include tpkg in the default bundler group, which resolves the issue.

But it still seems risky to define HashWithIndifferentAccess class in tpkg in the event that it's already defined by someone else.

Perhaps there is a way to conditionally create HashWithIndifferentAccess if it's not already defined by someone else (like ActiveSupport)?

some references
https://github.com/rails/strong_parameters
rails/strong_parameters#140

Allow pkgs to be deprecated or deleted

I have a tpkg I set up, but I ended up splitting it into 2 packages and I don't want anyone to use the old packages. Currently there is no way to mark (tag) packages as "Dear God don't use this" or to delete the package completely from the repo. I'm looking for either one of those solutions.

Was: https://sourceforge.net/apps/trac/tpkg/ticket/16

Provide more info with tpkg --qi option (ie: who uploaded, when uploaded, etc)

From Jim Yanko:

Could the commmand line output for package information be updated to include some of the info currently ONLY visible via the tpkg Web UI?

Currently, in the WebUI to the repository, I can see more info about a package than I can by using the command line tpkg utility...

The Web UI allows me to see all of the following info about a pacakge in the repo

• name
• Package file
• version
• package version
• the maintainer
• os
• architecture
• description of the pkg
• file info
  • when the tpkg was uploaded
  • WHO uploaded the package (maintainer is defined in the tpkg.yml, but the user who actually uploaded the binary is not necessarily the maintainer)
• what machines the pkg is installed on

Being able to retrieve all the same information via the command line tool would be nice.

Currently, we only get a subset of the above information
(I believe this is because --qX and --qi only display info from the .tpkg's .yml or .xml file content)

$ tpkg --qi eds_config_qa-2.10.0-5.tpkg
name: eds_config_qa
version: 2.10.0
package_version: 5
operatingsystem: any
architecture: any
maintainer: [email protected]
description: QA environment configuration settings for the Extended Distribution System (not intended for prod enviro install)
bugreporting: http://jira.example.com:8080/browse/YAH
This package depends on other packages, use --qd/--qld to view the dependencies.

Was: https://sourceforge.net/apps/trac/tpkg/ticket/15

tpkg --groups not working

tpkg --groups does not work

1. Does not execute the host_group_script with a group name parameter
2. Does not remove --groups=GROUPS from the deployment args causing a circular install

Support running tpkg as a non-root user

Currently several major tpkg features don't work if tpkg is not run as root, namely init scripts and crontabs. In both cases we currently hook into the related OS subsystem, which requires root privileges. Ideally these would be handled more like logrotate or stunnel where packages would express a dependency on a "cron" or "init" package and then drop crontabs or init scripts into /opt/tpkg/etc/cron.d or /opt/tpkg/etc/init.d and have them activated. The cron package could just run its own cron daemon and be completely independent of the OS cron system. This would eliminate the need for the flag in tpkg.xml. The init functionality is a little trickier, we would want a hook into the OS init system so that tpkg could start apps at system boot. It's not yet clear to me if we could eliminate the section of tpkg.xml.

On the cron front I looked around at the available options and it seemed to me vixie-cron was the most appropriate, but it is a crufty old-school package that wasn't easily relocated to /opt/tpkg.

Was: https://sourceforge.net/apps/trac/tpkg/ticket/14

Native stubbing, multiple versions of a package

If you attempt to install two versions of the same package which both depend on native packages then the stubbing code collides with itself. It should incorporate the version of the tpkg in the name or version of the native package to avoid this conflict.

% tpkg -q python
python-2.7.2-1-redhat6-x86_64.tpkg

% tpkg -i python=3.2.2
Executing with sudo
The following packages will be installed:
python-3.2.2-1-redhat6-x86_64.tpkg
Confirm? [Y/n]
Skipping bzip2, already installed
Skipping gdbm, already installed
Processing files: stub_for_python-1-1.noarch
Checking for unpackaged file(s): /usr/lib/rpm/check-files /tmp/rpmbuild20120910-8230-164886d-0/BUILDROOT/stub_for_python-1-1.x86_64
Wrote: /tmp/rpmbuild20120910-8230-164886d-0/RPMS/noarch/stub_for_python-1-1.noarch.rpm
Executing(%clean): /bin/sh -e /var/tmp/rpm-tmp.fRKBcR

• umask 022
• cd /tmp/rpmbuild20120910-8230-164886d-0/BUILD
• /bin/rm -rf /tmp/rpmbuild20120910-8230-164886d-0/BUILDROOT/stub_for_python-1-1.x86_64
• exit 0
  package stub_for_python-1-1.noarch is already installed
  Warning: Failed to install native stub package for python

Client should have option to send update on packages installed to server

Currently the client only sends an update to the server about what packages are currently installed at the end of an install/update/remove operation. It would be nice if the client had a command line option to send an update.

If the server is unavailable when an install/update/remove operation occurs then that update to the server will be lost. If the client doesn't have frequent install/update/remove operations then its state as recorded on the server may be incorrect for a long time. Users might want a way to update that state on the server manually or via cron without having to perform an install/update/remove operation.

Was: https://sourceforge.net/apps/trac/tpkg/ticket/38

Option to mark postinstall scripts as critical, in which case failure of said script triggers rollback of installation

In some cases postinstall scripts are needed to perform operations that are critical to the operation of the associated package, and if they fail to complete the package is certain to not operate properly. In those cases we should allow the packager to flag the postinstall script as critical, in which case a failure of the postinstall script triggers a rollback of the package installation. How best to "rollback" in the case that we're performing an upgrade will need to be determined.

Was: https://sourceforge.net/apps/trac/tpkg/ticket/2

Init script executable check should be smarter about permissions

Situation:

Init script permissions don't appear to allow root execution. I.e. script is owned by user "foo" and has 0700 permissions. In this case tpkg will warn that the script is not executable, even though root will still be able to execute it (by virtue of being root).

Need to confirm that the behavior of root executing things with any sort of execute bit set is fairly universal across Unix variants, then modify the permissions check in tpkg to account for that fact.

Was: https://sourceforge.net/apps/trac/tpkg/ticket/35

Better option handling

Currently options to tpkg are all handled by OptionParser, so install is specified as --install or -i. It would be nice to support the style supported by yum, gem, etc. of "tpkg install foo.tpkg". This would perhaps also give us an opportunity to work around OptionParser's somewhat clumsy handling of options which take multiple values. "tpkg -i rails-2.3.2.tpkg,actionmailer-2.3.2.tpkg" seems sub-par from a usability standpoint, particularly as "tpkg -i rails-2.3.2.tpkg -i actionmailer-2.3.2.tpkg" don't give you an error, but don't work as you expect either (the second instance of the option is silently ignored). Handling "tpkg install foo.tpkg" would mean doing our own option parsing after OptionParser is done, and we could properly handle things like ""tpkg install foo.tpkg bar.tpkg".

Previously: https://sourceforge.net/apps/trac/tpkg/ticket/1

Symlinks to directories are not removed

jheiss@sleet:~/projects/tpkg/junker> ls -l /opt/tpkg
total 0
drwxr-xr-x 3 root admin 102 Apr 19 09:46 var/

jheiss@sleet:~/projects/tpkg/junker> tpkg -i junker-1.tpkg

jheiss@sleet:~/projects/tpkg/junker> ls -l /opt/tpkg
total 16
drwxr-xr-x 2 root wheel 68 Apr 19 15:26 directory/
-rw-r--r-- 1 root wheel 0 Apr 19 15:26 file
lrwxr-xr-x 1 root wheel 9 Apr 19 15:26 link_to_directory@ -> directory
lrwxr-xr-x 1 root wheel 4 Apr 19 15:26 link_to_file@ -> file
drwxr-xr-x 3 root admin 102 Apr 19 09:46 var/

jheiss@sleet:~/projects/tpkg/junker> tpkg -r junker
The following packages will be removed:
junker-1.tpkg

jheiss@sleet:~/projects/tpkg/junker> ls -l /opt/tpkg
total 8
lrwxr-xr-x 1 root wheel 9 Apr 19 15:26 link_to_directory@ -> directory
drwxr-xr-x 3 root admin 102 Apr 19 09:46 var/

Tpkg send_update_to_server breaks on

Facter['fqdn'] can fail on cygwin, or hosts with a non-fqdn hostname and throw a 500 error on the reporting server.

Client should record where package came from

The client should record where a package came from, e.g. the repo URL or the file/directory. The should be displayed when the user lists the info for an installed package. That might help users debug issues.

Ability to sign (and verify signature of) packages

From Carl Johnson:
Similar to RPM and other packaging systems, it would be helpful if tpkg offered the ability to sign packages, and for the tpkg utility to verify such package signatures.

Was: https://sourceforge.net/apps/trac/tpkg/ticket/8

Tpkg should control starting init scripts on system boot, rather than linking them into the system init area

If a package has init scripts tpkg currently symlinks those into an appropriate OS directory so that they are started at system boot time. In order to increase portability, and to give us more control over the process, we should have tpkg insert its own init script into an appropriate system location and then start all package init scripts itself.

One item in particular that this would enable is for us to source /opt/tpkg/etc/profile.d/* before running init scripts, as it is a common feature request that users be able to set environment variables that are always available to their application.

Was: https://sourceforge.net/apps/trac/tpkg/ticket/13

add additional flag to --ql to show md5 sum of file alongside the file name

it would be nice if there was an additional flag in addition to --ql to display the md5sum of a file next to the file name. This would make it easy to see what files changed between tpkg versions.

Was: https://sourceforge.net/apps/trac/tpkg/ticket/20

Options to configure default owner, group and permissions

The default file ownership, etc. are currently hard-coded as constants in tpkg:

DEFAULT_OWNERSHIP_UID = 0
DEFAULT_OWNERSHIP_GID = 0
DEFAULT_FILE_PERMS = nil
DEFAULT_DIR_PERMS = 0755

They should be user configurable.

Option to save individual deployment results to file

Currently we report the results of deployment to specific hosts by displaying a ruby data structure at the end of the deployment process:

% tpkg -s bogushost,realhost --qa

Exit statuses:
{"realhost"=>0, "bogushost1"=>1}

Users have pointed out that this is not ideal. If they want to access the individual status programmatically they have to parse the output, find this data structure, and read it back in via ruby. It would be much more convenient if we had an option to save individual status to a file, particularly in a more generic format like yaml.

Was: https://sourceforge.net/apps/trac/tpkg/ticket/32

Consider splitting out deployment functionality to a separate executable

The tpkg executable currently handles all of the local package operations as well as deployment to remote servers. The deployment functionality is rather different from the local package operation functionality in that it strips out any deployment-related command line options from the command line options that the user specified, then executes tpkg on the remote machines over ssh, replaying all the non-deployment options.

I haven't convinced myself one way or the other yet, but I think there's cause to believe we should move the deployment functionality to a separate executable (perhaps tdeploy?) The mechanism by which we strip out deployment-related options is fragile (see note in code comment for details) and would be hard to make robust. And more generally they seem like two different sets of functionality and having them in a single executable contributes to the overwhelming number of tpkg options and the general feeling that tpkg is too complex.

Was: https://sourceforge.net/apps/trac/tpkg/ticket/47

Add "replaces" to compliment "conflicts"

We should allow users to indicate that a package replaces another package. I.e. the package used to be named foo and is now named bar, i.e. bar replaces foo. In that case we would always silently replace foo with bar if bar were explicitly requested or came in via dependencies. This compliments the "conflicts" option, which serves to say that two packages do the same thing and we don't want both installed at the same time, but don't have a preference between the two. "replaces" indicates that we do have a preference, and should automatically update to the "replaces" package.

Was: https://sourceforge.net/apps/trac/tpkg/ticket/12

tpkg should not allow the user to specify the same tpkg as a dependency

right now you are allowed to create a tpkg with a dependency of itself which causes an endless cycle of tpkg calculating the dependencies.

example yaml file:

name: glusterfs
version: 3.0.5
package_version: 1
operatingsystem: [CentOS-5]
architecture: [x86_64]
dependencies:
  - name: glusterfs

I realize that it would be a rare case that a user would do this and it only came up when a coworker was creating a tpkg which installed an rpm of the same name, but the coworker forget to specify the dependency was a native dependency.

Was: https://sourceforge.net/apps/trac/tpkg/ticket/19

Move config file parsing from tpkg executable to tpkg.rb

Config file parsing should be done in the library rather than the executable so that all users of the library benefit from config file support.

Additionally the path for finding tpkg.conf should respect the file_system_root option to allow for unit testing of the config file parsing. I added this to etch recently and it could serve as an example.

Was: https://sourceforge.net/apps/trac/tpkg/ticket/28

Bittorrent support for package distribution

The tpkg client caches all packages it has ever installed. It seems like it wouldn't be too hard to have an option for the clients to act as bittorrent nodes, serving up the packages to other clients.

Dependency calculation on remove, multiple versions of same package installed

Dependency calculation seems to be broken when deciding whether the user can remove a package when there are multiple versions of the same package installed. In this case I had two versions of ruby installed and attempted to remove one. There should not have been a dependency problem with removing the package.

jheiss@typhoon:~> tpkg -q ruby
ruby-1.9.3-p194-1-redhat6-x86_64.tpkg
ruby-1.8.7-p358-1-redhat6-x86_64.tpkg

jheiss@typhoon:~> tpkg -r ruby-1.9.3-p194-1-redhat6-x86_64.tpkg
Executing with sudo
[sudo] password for jheiss:
/usr/lib/ruby/site_ruby/1.8/tpkg.rb:4208:in remove': Package nventory-1.62.8.tpkg depends on gem-facter (RuntimeError) from /usr/lib/ruby/site_ruby/1.8/tpkg.rb:4201:ineach'
from /usr/lib/ruby/site_ruby/1.8/tpkg.rb:4201:in remove' from /usr/lib/ruby/site_ruby/1.8/tpkg.rb:4198:ineach'
from /usr/lib/ruby/site_ruby/1.8/tpkg.rb:4198:in `remove'
from /usr/bin/tpkg:611

jheiss@typhoon:~> tpkg --qd gem-facter
Package gem-facter-1.5.8-1.tpkg depends on:
name: rubygems
type: tpkg

jheiss@typhoon:~> tpkg --qd rubygems
Package 'rubygems' does not depend on other packages

Was: https://sourceforge.net/apps/trac/tpkg/ticket/49

Remove packages in dependency order

There is logic in tpkg to install packages in dependency order, but no logic to remove them in reverse dependency order.

Expose inequality support in package metadata

Packages currently can express dependency versions via min/max version, min/max package version, and allowed versions. Recently in order to support inequality on the command line (tpkg -i ruby>=1.9 for example) I added version greater/less than and package version greater/less than support to the tpkg library. We should expose that functionality in package metadata so that packages can express their dependencies using that functionality. gem2tpkg in particular needs this to properly translate gem dependencies to tpkg dependencies, it currently uses crappy workarounds.

Was: https://sourceforge.net/apps/trac/tpkg/ticket/45

Force install

Please add an option to force the installation of a package if the OS and/or ARCH do not match the current box. The example that comes up over and over for me is a package that is compiled for CentOS or Red Hat but will not install on Ubuntu.

Was: https://sourceforge.net/apps/trac/tpkg/ticket/17

tpkg --downgrade doesn't work if there's dependency among the packages

Supposed we have the following packages:

• pkgA-1 and pkgB-1. pkgB-1 has dependency on pkgA (min version 1).
• pkgA-2 and pkgB-2. pkgB-2 has dependency on pkgA (min version 2).

If pkgA-2 and pkgB-2 are installed, we won't be able to do tpkg --downgrade pkgA=1. Tpkg needs to be smart enough to downgrade pkgA to version 1 AND then downgrade pkgB to version 1.

Was: https://sourceforge.net/apps/trac/tpkg/ticket/9

Deployment failures should translate into non-zero tpkg exit value

Deployment failures currently are not reflected in the tpkg exit value.

% tpkg -s bogushost --qa

Exit statuses:
{"bogushost"=>1}
jheiss@ypcmc03414:~> echo $?
0

Was: https://sourceforge.net/apps/trac/tpkg/ticket/31

cpan2tpkg not creating tpkg for LWP::UserAgent and HTTP::Date

instead it spits out these three tpkg'd perl modules for LWP::UserAgent and HTTP::Date:

cpan-perl510-HTML-Parser-3.66-1-redhat5-x86_64.tpkg
cpan-perl510-HTML-Tagset-3.20-1.tpkg
cpan-perl510-URI-1.54-1.tpkg

Was: https://sourceforge.net/apps/trac/tpkg/ticket/4

cpan2tpkg and modules with non-complaint version numbers

Mail::SPF seems to have version "v2.007", which doesn't meet the tpkg requirement that a version start with a number. cpan2tpkg should give the user an option to force a different version number (allowing the user to set the version to 2.007 in this case).

Installing /tmp/S6Hvk1aRQI/home/t/bin/spfquery
JMEHNLE/mail-spf/Mail-SPF-v2.007.tar.gz
./Build install – OK
Installed modules to be packaged (except Perl):
Mail::SPF, Perl
Packaging Mail::SPF
Use of uninitialized value $ver in concatenation (.) or string at /usr/bin/cpan2tpkg line 226.
Module version is
Package name, based on distribution, is Mail-SPF-v2.007.tar.gz
Running Build for J/JM/JMEHNLE/mail-spf/Mail-SPF-v2.007.tar.gz
Has already been unwrapped into directory /home/pobrien/.cpan/build/Mail-SPF-v2.007-k7eCGm
Has already been made
Argument "\x{76}\x{35}..." isn't numeric in numeric gt (>) at /usr/bin/cpan2tpkg line 266.
Prereq version is a core module, skipping
Packaging into /tmp/uYPo4JkLpN
Use of uninitialized value $ver in concatenation (.) or string at /usr/bin/cpan2tpkg line 326.
Bad metadata file. Possible error(s):
Required field version not found
Version must begins with a digit
/usr/lib/ruby/site_ruby/1.8/tpkg.rb:311:in `make_package': Failed to create package. (RuntimeError)
from /usr/bin/tpkg:388

Was: https://sourceforge.net/apps/trac/tpkg/ticket/3

tpkg should allow user to specify whether to use 32bit or 64bit version package for native dependency

Unable to find any packages which satisfy oracle-native-dependencies. Possible error(s):
Requested package oracle-native-dependencies-1.0-redhat-multiarch.tpkg depends on {"name"=>"libXtst.i386", "type"=>:native, "native"=>true}, no packages that satisfy that dependency are available
/usr/lib/ruby/site_ruby/1.8/tpkg.rb:3190:in check_requests': Unable to satisfy the request(s) (RuntimeError) from /usr/lib/ruby/site_ruby/1.8/tpkg.rb:3367:ininstall'
from /usr/bin/tpkg:388

$ yum list libXtst.i386
Loaded plugins: rhnplugin, security
Note Red Hat Network repositories are not listed below. You must run this command as root to access RHN repositories.
base | 1.1 kB 00:00
base 3040/3040
updates-released | 951 B 00:00
updates-released 3087/3087
ypc-released | 951 B 00:00
ypc-released 166/166
Available Packages
libXtst.i386 1.0.1-3.1 base

Was: https://sourceforge.net/apps/trac/tpkg/ticket/6

Current file permissions not preserved

Reported by Raymond Barbiero via email:

Say that tpkg a writes a file to /home/t/etc/a
Say that tpkg b writes a file to /home/t/etc/b

Tpkg a specifies:
file_defaults:
posix:
owner: t
group: roleusers

Tpkg b specifies (or has no file_defaults):
file_defaults:

Tpkg a is installed first. Ownership of the /home/t and /home/t/etc are now set to t:roleusers
Tpkg b is installed second. Ownership of /home/t is now root:root and /home/t/etc is now owned by root:root

Improve reporting of dependency resolution failures

We added some checking for the availability of the dependencies of the package that the user is trying to install. If any of those are unavailable we give the user a message like "Unable to find any packages which satisfy ". However, that checking only goes one level deep. If all versions of the package depend on some package which in turn has dependencies we can't satisfy the user currently just gets the "checked 10000 solutions" error, which is very non-specific and confusing. Somehow we should give the user more specific feedback.

Note that this is somewhat difficult because various versions of packages and dependencies that we check can be unsatisfiable for different reasons and reporting on all of those could be overwhelming. Perhaps we should just reporting on any dependency failures for the most recent version of each candidate package?

Was: https://sourceforge.net/apps/trac/tpkg/ticket/26

Throw error on unpack if all files in package are encrypted and passphrase is not supplied

We normally allow a package containing encrypted files to be installed even if the user does not supply the passphrase to decrypt the files. We just skip installing the encrypted files. This allows developers to install packages with production credentials in non-production environments for testing, etc.

However, if a package only contains encrypted files it doesn't make sense to allow folks to install it if they don't provide the passphrase, as no files would get installed.

Was: https://sourceforge.net/apps/trac/tpkg/ticket/11

CLI options to start/stop/restart/reload a tree of packages

A coworker expressed a desire for an option to start/stop/etc. all packages that a package depends on. So if you have "myapp" which depends on nginx and mysql, this option would start/stop/etc. myapp, nginx and mysql. Perhaps something like --start-depends or --start-recursive. Not a huge fan of either of those, so if you come up with something better that's great.

Was: https://sourceforge.net/apps/trac/tpkg/ticket/10

tpkg - needs a upload package binary option to upload packages to repo

From Jim Yanko:

Would like to see tpkg provide an option to just upload a tpkg binary to the repository.

tpkg —upload eds-5.22.5-5.tpkg # something like this would be nice

We already have a --download option, and there is a side script which performs upload, but it is not integrated to the main tpkg tool.

The script that is used for uploading is.

tpkg_uploader.rb -f $HOME/TPKGBUILD/scratch/eds_config_qa-2.10.0-16/eds_config_qa-2.10.0-16.tpkg

Which is currently installed by another tpkg tpkg_uploader-1.5-4.tpkg itself

$ tpkg --qf /Users/jyanko/tpkg_test/home/t/bin/tpkg_uploader.rb
/Users/jyanko/tpkg_test/home/t/bin/tpkg_uploader.rb: tpkg_uploader-1.5-4.tpkg

Since tpkg is used to create new packages, it would be nice for it to provide a little cleaner way to upload packages to the repo after they're created.

Was: https://sourceforge.net/apps/trac/tpkg/ticket/5

Option parsing for package name does not handle os/arch changes well

The context here is that the box in question was running a beta version of Debian. A version of collectd was built and installed. The box was then upgraded via apt-get to the released version of Debian, which changed the tpkg OS value from "Debian-testing" to "Debian-7". While that understandably leaves tpkg in a bit of a mess, there's no reason that referring to the installed collectd package by the bare package name shouldn't continue to work.

jheiss@office:~> tpkg --qa
collectd-5.1.1-1-debiantesting-armv6l.tpkg

jheiss@office:~> tpkg -r collectd
No matching packages

jheiss@office:~> tpkg -r collectd-5.1.1-1-debiantesting-armv6l.tpkg
The following packages will be removed:
collectd-5.1.1-1-debiantesting-armv6l.tpkg
Confirm? [Y/n]

Consider moving tpkg executable logic to library

Most other ruby command line apps that I've seen have all of their executable logic in a library file. The actual executable file is then usually extremely short, just "require"ing one or two library files. I haven't looked much yet to see if there's an obvious reason why they structure things this way. Possibilities that occur to me might be easier unit testing and/or allowing users to repurpose CLI functionality in their own applications. We should investigate this further and decide if this approach should be taken for the tpkg executable.

Was: https://sourceforge.net/apps/trac/tpkg/ticket/46

tpkg --ql not listing symlinks properly

% tpkg --ql ruby-defaults-1.8-1.tpkg
:
/opt/tpkg/bin/
/opt/tpkg/bin/ri
/opt/tpkg/bin/irb
/opt/tpkg/bin/ruby
/opt/tpkg/bin/erb
/opt/tpkg/bin/rdoc

% tpkg --ql ruby-defaults
ruby-defaults-1.8-1.tpkg:
/opt/tpkg/bin

% tar zxvf tpkg.tar.gz
tpkg/
tpkg/tpkg.xml
tpkg/file_metadata.bin
tpkg/reloc/
tpkg/reloc/bin/
tpkg/reloc/bin/ri
tpkg/reloc/bin/irb
tpkg/reloc/bin/ruby
tpkg/reloc/bin/erb
tpkg/reloc/bin/rdoc

The problem with listing the files in ruby-defaults seems to be related to those files being symlinks. There are no references to those files in the saved file metadata when the package is installed and self.files_in_package is using that data as a shortcut if the package is installed.

Was: https://sourceforge.net/apps/trac/tpkg/ticket/21

Some packages with large dependency trees cause tpkg to hit the 10000 solution limit

I've seen a few reports now of various packages, tending to have fairly large dependency trees, where attempts to install the package sometimes cause tpkg to hit the 10000 checked solution limit before it finds an acceptable solution.

Usually the problem is encountered when few to none of the dependencies are already installed. I've generally been able to work around that by manually installing some of the dependencies, thus reducing the size of the problem that tpkg has to solve when installing the main package.

I suspect this is due to the dependency resolution code in tpkg using a nil value at the start of the array of possible packages to indicate that there is no acceptable version of that package currently installed. (This is done to ensure that already installed packages score higher than not installed packages.) This causes tpkg to have to check a lot of solutions involving a 'nil' entry for that particular package and discard them, before eventually getting to possible solutions using later items in the array.

Was: https://sourceforge.net/apps/trac/tpkg/ticket/22