Joerg Schilling wrote:
Not correct:
I propose to replace the current /usr/bin/tar by a star based emulation
_after_ it did add support for the options -@ and -T.
Ah, this is goodness. Sorry, I must have misunderstood.
The suntar implementation for -T uses an undocumented archive format, so
star may safely use a different archive format to implement this feature
once a desription for this feature is available.
You are missing the point: The ON DISK ARCHIVE FORMAT is also a
Committed interface - the tar command MUST always be able to read
and process old archive files.
Of course, as long as you can read old -T archives, there is nothing
that says that you could't change tar's implementation of -T to use
a different/better archive file format.
In order to satisfy users from a former _different_ Sun product named
"Trusted Solaris", we would need to keep a copy of the current binary
under the name /usr/bin/otar. This binary could also satisfy the needs of
people who like to move data from a recent Solaris version to an older
version when using [EMAIL PROTECTED]
or implement the behavior in the replacement you are providing...
The consequence of promising stability over time is that
you can not inflict incompatible change in areas that
were promised to be stable.
I could understand (note I am not saying "like" or "approve"!) if
the new tar was documented/implemented to simply invoke this "otar":
If the -@ option is given, it restricts the other
options that can be used to those supported by Sun's
old tar, namely [...]. If -@ is seen when parsing
the command line options, tar will exec otar to do
all the required processing.
I just explained why we do not need a Major release update for this change.
Having scripts that use -@ fail after your tar is integrated
misses the stability point completely, as does having a new
tar that won't read/process the old archives.
Under the release taxonomy rules, you can't make those kinds of
incompatible changes in a Minor release.
Agree that a committed interface is something that has been documented.
Agree that the current suntar implementation uses an undocumented
archive format in order to implement -T. For this reason, only the
documented feature (-T and the visuble effects) need to be implemented
in star.
You are missing the point - there are Committed interfaces that
are both public and private. Both are valid. Consider:
From a pure consumer perspective, the Public Committed interfaces
are ones that we expect others to use/reuse. These interfaces find
their way into other project's scripts, sysadmin tools, ISV
documentation, etc. You seem to be stuck in this world view.
The other perspective is that of a robust producer - you may have
a whole slew of interfaces that you have Committed to supporting
over time, even though none of them are exposed to your consumers.
Things like file formats are a common example of Committed Private
interfaces since new versions of your program need to be able
to read files created by old versions.
The difference is that we expect users to use the tar command
and its options to create and manipulate tar archives and we don't
expect them to open a tar archive file in emacs to manipulate it
directly, yet we expect the tar command to always be able to read,
extract and otherwise manipulate archive files created by every
old version of tar that ever existed.
-John
_______________________________________________
opensolaris-code mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
