pkg-2.4

	Free Downloads, Community Forum, FAQs and Developer Resources

Make /Tools Your Home | Link to us

Today's posts | Posts since last visit | Most Active Topics

All Forums	Register	Login	Search	Subscriptions	My Profile	Inbox
Tool Warehouse	FAQs	Resources	Help	Member List	Address Book	Logout

pkg-2.4

Logged in as: Guest

Users viewing this topic: none

Printable Version

All Forums >> [Announcements] >> Tool Warehouse Updates >> pkg-2.4

Page: [1]

Message

<< Older Topic Newer Topic >>

pkg-2.4 - Jul. 19, '05, 11:21:36 PM

Rodney

Posts: 3714
Joined: Jul. 9, '02,
From: /Tools lab
Status: offline

Announcing pkg version 2.4 for Interix.

This is an update to the previous release to add enhancements.
You can update now without any changes needed to your behavior
for installing any of the packages.

These enhancements are for the future (Nov/Dec 2005) when the
Windows 2003 Server R2 release of Interix 5.2 (aka SUA) will be
available for 32-bit and 64-bit platforms while Interix 3.5
is still being supported. As such these changes will not be all
that noticable to users (installers). Packagers (people building
packages) will have a few new commands to help get packages
correctly installed on the right Interix release/hardware.
More details below and on the manual pages.

To update do:

    pkg_update -L pkg

    pkg_add ftp://ftp.interopsystems.com/pkgs/3.5/pkg-current-bin.tgz

More details:
Since the upcoming Interix 5.2 (SUA) release will be available on 32-bit
and 64-bit systems the directory locations have a slight pathname change
at the default ftp site. For backward compatability the "3.5" directory
and the new "3.5-x86" directory are symbolic links. The new 5.0 directory
is "5.2-x86" for Interix 5.2 on 32-bit. For 5.2 on 64-bit there may be
two directories: one for AMD 64 bit and another for Intel IA 64-bit. But
this will be set at later for final directory names.
Anyway... the reason for this is so users can run pkg_update on any
machine and the right package for the right Interix release/hdwr combination
will just happen. Granted, most of these "users" should be sysadmin's, but
everyone likes easier and it means fewer support questions.

Since changes/additions to any OS happen as releases happen there are two new
commands for pkg_create: "@uname-r" and "@uname-r+". This allows you
to specify that the package is only for a particular release or for a release
plus subsequent release respectively.

While 32-bit "thunking" will be available on the 64-bit platforms it's always
best to have 64 on 64. Also you can't do 64-bit thunking onto 32-bit.
So a new command of "@uname-p" allows for a package to be identified for
a particular processor/hardware.

If none of these new commands are specified then release and/or processor
are assumed to be okay. If specified then an installation won't proceed
(with a matching error message of course).

Here are some scenarios:
1)
A package consisting entirely of shell scripts won't need these new commands
because the scripts and the script files are portable.
2)
An existing package for 3.5 that continues to run on 3.5 plus appears to
run without a problem on 5.2-x86 (32-bit). However, for speed to you want
to have a specific 64-bit package. So you use "@uname-p" in your package.
3)
Same as (2) but you've now made an enhancement using a new API only available
in 5.2. The "old" package still can run on 5.0 so you leave it alone and
to your new package bundling you specify "@uname-r+ 5.2". This will ensure
the new package won't be installed on an earlier version than 5.2 and croak
causing you lots of support grief.

< Message edited by Rodney -- Jul. 20, '05, 12:20:39 AM >