Check-in [5b9d91f33f]

Login
Bounty program for improvements to Tcl and certain Tcl packages.
Tcl 2019 Conference, Houston/TX, US, Nov 4-8
Send your abstracts to tclconference@googlegroups.com
or submit via the online form by Sep 9.

Many hyperlinks are disabled.
Use anonymous login to enable hyperlinks.

Overview
Comment:Reworked the starpack section to explain that both unified and split namespace are useful. Filled section testing, and added the miscellanea about `package prefer stable`.
Downloads: Tarball | ZIP archive | SQL archive
Timelines: family | ancestors | ak-529-provisional-tcl-installation-types
Files: files | file ages | folders
SHA3-256:5b9d91f33fe2d2655e9966b67c3a20a796d14dba9b60f73a7f168f30822e2f64
User & Date: aku 2018-12-09 04:29:10
Context
2018-12-09
04:29
Reworked the starpack section to explain that both unified and split namespace are useful. Filled section testing, and added the miscellanea about `package prefer stable`. Leaf check-in: 5b9d91f33f user: aku tags: ak-529-provisional-tcl-installation-types
2018-12-07
00:06
Filling in blanks, tweaking existing phrasing somewhat check-in: f415db5a75 user: aku tags: ak-529-provisional-tcl-installation-types
Changes
Hide Diffs Unified Diffs Ignore Whitespace Patch

Changes to tip/529-provisional.md.

65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
...
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
...
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
...
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
...
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219

220

221










222
223


224









225
226






227

228




229



230
231
232
233
|4	|Self-made		|
|5	|Starpack/kit		|
|6	|s.a with plugin system	|
|7	|Testing		|

The following sections expand on each of these.

# System

This kind of installation is provided by an operating system (OS)
through its (OS) package manager (OPM). Both Tcl core and packages are
usually placed in system directories (requiring root/admin
permissions).

The OPM tools often have hooks to run package-specific pre/post
................................................................................

Irrelevant from a technical perspective, but important to users, the
selection of available Tcl packages is often limited as the OS
vendors/distributors have limited development bandwidth to wrap their
package management around Tcl packages.  Especially when a Tcl package
has a ... gnarly ... build system.

# Semi-system Installation

Like a system installation, except that the tools used, i.e. the
package manager, comes from a third party instead of the OS
distributor.

The tools may or may not handle package dependencies.

................................................................................
Examples:

|OS		|Package Manager|
|---		|---		|
|OS X / Darwin	|macports	|
|OS X / Darwin	|homebrew	|

# Pseudo-system Installation

Another step away from the OS a pseudo system installation is similar
to a semi-system installation, except it and its tools are now focused
on Tcl and Tcl packages, and does not concern itself with any other
type of package the user may wish to install.

The associated PM usually installs into user-controlled areas, not
................................................................................
|Name		|Vendor			|
|---		|---			|
|ActiveTcl	|ActiveState		|
|Teaparty	|Roy Keene		|
|IronTcl	|Joe Mistachkin		|
|MagicSplat	|Ashok P. Nadkarni	|

# Self-made Installation

A user builds and installs Tcl and any Tcl packages she needs by
herself.

User- or system directories may be used.

There are usually no tools for package management.

The user does all the dependency tracking.

The previous notes about installation and removal at will, and the
package namespace still apply.

# Starpacks/kits

While most people will see these as applications, from a technical
perspective these are installations as well, just limited to the
packages needed by the particular application, and conjoined with that
application into a single file.

Packs and kits effectively differ only in if the Tcl core needed for
................................................................................

Packages are are "installed" when the pack/kit is generated, and are
never removed. Future installation and removal at will is not
supported.

The package still exist in a single namespace.

# Starpacks/kits with plugin system

An application deployed in pack or kit form may allow extension by the
user in the form of some kind of plugin system. A possible
implementation would have the application reach out to an external
installation to find more packages, specifically the packages
implementing plugins for it.

Here we have a split physical space for packages. Those installed in
the application, and those outside.

While a unified namespace crossing the physical split is possible this
is actually not a good thing, as changes in the environment can then
break the application, i.e. when packages installed inside the
application are ignored favor of packagtes installed outside and

having the same name. This can be used to attack such applications.












A better model is to consider the namespace split as well, and search
the outside namespace if and only if a package i not found inside.












# Testing



















# Copyright

This document has been placed in the public domain.







|







 







|







 







|







 







|













|







 







|










|
|
|
<
>
|
>

>
>
>
>
>
>
>
>
>
>
|
<
>
>

>
>
>
>
>
>
>
>
>
|

>
>
>
>
>
>

>

>
>
>
>

>
>
>




65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
...
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
...
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
...
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
...
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218

219
220
221
222
223
224
225
226
227
228
229
230
231
232
233

234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
|4	|Self-made		|
|5	|Starpack/kit		|
|6	|s.a with plugin system	|
|7	|Testing		|

The following sections expand on each of these.

## System

This kind of installation is provided by an operating system (OS)
through its (OS) package manager (OPM). Both Tcl core and packages are
usually placed in system directories (requiring root/admin
permissions).

The OPM tools often have hooks to run package-specific pre/post
................................................................................

Irrelevant from a technical perspective, but important to users, the
selection of available Tcl packages is often limited as the OS
vendors/distributors have limited development bandwidth to wrap their
package management around Tcl packages.  Especially when a Tcl package
has a ... gnarly ... build system.

## Semi-system Installation

Like a system installation, except that the tools used, i.e. the
package manager, comes from a third party instead of the OS
distributor.

The tools may or may not handle package dependencies.

................................................................................
Examples:

|OS		|Package Manager|
|---		|---		|
|OS X / Darwin	|macports	|
|OS X / Darwin	|homebrew	|

## Pseudo-system Installation

Another step away from the OS a pseudo system installation is similar
to a semi-system installation, except it and its tools are now focused
on Tcl and Tcl packages, and does not concern itself with any other
type of package the user may wish to install.

The associated PM usually installs into user-controlled areas, not
................................................................................
|Name		|Vendor			|
|---		|---			|
|ActiveTcl	|ActiveState		|
|Teaparty	|Roy Keene		|
|IronTcl	|Joe Mistachkin		|
|MagicSplat	|Ashok P. Nadkarni	|

## Self-made Installation

A user builds and installs Tcl and any Tcl packages she needs by
herself.

User- or system directories may be used.

There are usually no tools for package management.

The user does all the dependency tracking.

The previous notes about installation and removal at will, and the
package namespace still apply.

## Starpacks/kits

While most people will see these as applications, from a technical
perspective these are installations as well, just limited to the
packages needed by the particular application, and conjoined with that
application into a single file.

Packs and kits effectively differ only in if the Tcl core needed for
................................................................................

Packages are are "installed" when the pack/kit is generated, and are
never removed. Future installation and removal at will is not
supported.

The package still exist in a single namespace.

## Starpacks/kits with plugin system

An application deployed in pack or kit form may allow extension by the
user in the form of some kind of plugin system. A possible
implementation would have the application reach out to an external
installation to find more packages, specifically the packages
implementing plugins for it.

Here we have a split physical space for packages. Those installed in
the application, and those outside.

As for the logical space, there are two ways of going about, both
equally valid. Which is chosen is very much dependent on the
application and its environment.


The first option is to simply have a unified namespace, like in all
the other installations coming before.

The main consequence of going this route is that packages installed
outside of the application may be able replace packages installed
inside. This may or may not be what is wanted for the application.

A reason for not wanting this is that such replacements may not be
compatible with the packages inside, and break the application. for
the more attack-minded this would be a way to alter the application,
i.e. change, remove, or inject functionality, or just spy on the
internals.

Thus the second option, keep the package namespace split as well, and

have packages found in the inside namespace be prefered over packages
in the outside namespace, regardless of relative version.

This this package replacement and attacks based on it are not possible
anymore. In counterpoint it is not possible (anymore) to fix bugs in
the application by providing fixed packages outside either. A newly
made application will be needed.

Both point and counterpoint hopefully demonstrate that both forms of
an extensible starpack/kit are sensible and useful, depending on
circumstances.

## Testing

When it comes to testing a (set of) package(s) during development what
we want is pretty much like an extensible starkit geared for
security. I.e. a package space split both physical and logical, with
the packages under test prefered over any in the environment,
regardless of version. The difference is of course that the prefered
space is not placed into a single file, like starpacks/kits.

# Miscellanea

Tcl's existing package system already offers a way of splitting a
package space, through `package prefer stable`. Note however that this
is a split along version lines, where stable versions of packages are
prefered over alpha or beta versions of the same.

The splits discussed above on the other hand are all very much not
about giving different weights to classes of versions, but about
giving different weight to classes of locations of installed packages.

# Copyright

This document has been placed in the public domain.