> In the case of the Mamfiles it's IMO "documentation". We check-in these > files and keep them updated to have a reference point for the matching > OS/Net Makfiles. I know that this is not perfect but it's at least > economical for those who work on the current tree (e.g. April and me). > Currently we can deploy updates within less than an hour (excluding > testing and a full OS/Net build) and randomly removing files will only > cost more time since the more or less automated procedure will no longer > work and then patches need to be applied by hand which takes far longer.
But for many others, it's just cruft in the gate. I definitely could understand it if the source directory was being dropped in situ into the source base but that's not the case here. For good reasons, you're putting the libraries with the other libraries and at some point, it's not clear if keeping the files which don't really serve a purpose as documentation (at least for OpenSolaris.) Anyway, this is something for you to work with the C-team on. >> I'm not trying to reopen this ON-versus-SFW debate here but the >> discussion around these files is precisely because you're trying to >> integrate this into ON. Consolidations such as SFW work much more in a >> pass-through mode - the source comes from upstream, undergoes a small >> amount of change (if any at all) and then is compiled and packaged via >> some sort of mechanism (perhaps a Sun-supplied master Makefile and the >> open source project's own ./configure script). > > Grumpf... part of the decision to put ksh93 into OS/Net is that it is > (or better: should be) the successor of the old korn shell which was in > OS/Net, too. We'd like to run the work under the same rules to make sure > noone can throw the "(shell-)flavor of the day"-stones after us once we > run the ARC case for the "/usr/bin/ksh to ksh93"-migration. Please understand that there really is no correlation here. I can understand wanting from an aesthetic point of viewing delivering ksh93 through the same consolidation as the Sun ksh88 but it doesn't have to be the case. Even delivering it via SUNWcsu isn't really necessary because other packages can be designated as "core packages" (in this case, we're talking about the Sun branded Solaris distribution and your mileage may vary with other packaging systems and distributions.) In any case as I said, I'm not trying to reopen that decision but rather point out that some of the difficulty we're having here is because ksh93 is more in keeping with other source that comes from an external/upstream community. >> That certainly is a good argument if bourne shell implementation is >> unreadable. But there seem to be some Makefiles where I didn't see any >> ksh93 constructs at all, or minimal ones at that. For example, why the >> changes to libcmd's Makefiles to use /bin/ksh? > > Because libcmd's Makefile "include"s things like "Makefile.libastl10n" > and "Makefile.astinclude". I know that this functionality could be > re-done using SHELL=/bin/sh which then calls scripts which use > "#!/usr/bin/ksh" and do the same job - the question is whether this is > really neccesary when the same could be done in the Makefile's itself > with less effort. Thanks for the pointers to the included Makefiles. Although I didn't really see any ksh'isms in Makefile.libastl10n, I did noticed them in Makefile.astinclude. >>>> 3. With respect to the *.so library links and the the lint >>>> library, I think including these in an internal package is fine >>>> but I do not believe they should be actually included in any >>>> metacluster at this time. From my understanding of the >>>> contents of the SUNWastdev packages, that also holds true for >>>> it as well. >>> >>> Erm, the primary purpose of the "SUNWastdev" package is to deliver AST >>> development tools to /usr/ast/bin/. It was not intended to become a >>> dumping ground for everything. >> >> Thanks for the explanation. I went back to PSARC 2007/035 and it does >> seem that this package should contain just the components presented in >> that case. > > Did you read the explanation what the "SUNWastdev" package is used for > in the future ? Yes I did, but the future is just that - it's something that we expect and hope will take place but it hasn't yet. This is especially important with exposing interfaces which we don't wish to make available yet. We should not be exposing things which are likely to cause confusion or brokenness until our "commitment" to them (hence the notion of an "ARC commitment level") has risen to the appropriate level. In the case of SUNWastdev, although it's contents are currently at Volatile, there are necessary dependencies that are at a lower commitment level so actually including this package in the WOS seems premature to me. >> But I do have one question for SUNWastdev. If the *.so library links >> for libshell, libast, libdll, and libcmd (and libpp, for that matter) >> are not supplied, is this package actually usable by anyone? Let's >> leave out the ON developers but rather focus on the end-developer who >> is wishing to use the AST development tools. Do these tools depend on >> linking against the currently project private libraries? > > Yes, they link against libast and some against libpp. > >> Put another >> way, should this package me an internal-only package right now because >> the end-developer cannot use it given the commitment level that was >> ARCed? > > What do you mean with "internal-only package" ? And see my question By internal, it would be built as part of the ON build process but it would not be included at this time in the WOS. When you install Nevada, you wouldn't see the package installed on the system. However, it would be available for those with ON build machines. > above about the future target of the package (like the other ksh93 and > AST components we'd like to put them into their correct places from the > beginning... anything else (like moving files etc. around) will just > generate more paperwork which will consume much time (at least I am a > volunteer and (unfortunately) have to work for food on other stuff > (which means I don't like to spend time on paperwork unless it's really > mandatory))). When the commitment level of the required interfaces in libshell, etc are raised, you wouldn't need to move any components but rather add in the *.so links and the lint libraries. The amount of so-called paperwork is minimal - besides a PSARC fast-track, there is a short ASCII form called a "package RTI" that tells the Solaris Release Engineering group to include this package and which meta-cluster is appears in. >> Do add a Sun copyright to files which have a significant >> change. The definition of the latter is sometimes hard to >> define but changing it to make it compile or work under >> OpenSolaris clearly falls in the "add" category. In any case, >> please check with Bonnie. > > What about a file where we added an |#include|-statement to include > another (CDDL-)licensed chunk of code ? The |#include|-solution was used > to avoid the situation that we have to add a license template to the > AT&T sources... In my opinion, you still would add a Sun copyright in this case but please ask Bonnie Corwin - she's the right OpenSolaris person to clarify the situation. >>>> usr/src/lib/libast/amd64/Makefile >>>> >>>> Line 31 - Is there a reason you're only using the minor part >>>> here rather than the whole $(RELEASE) string? Is there some >>>> standard here that ksh93 uses with different OS versions? >>> >>> See may reply to James Carlson's email >>> (http://mail.opensolaris.org/pipermail/ksh93-integration-discuss/2007-February/002225.html). >>> Basically the upstream code uses this as a platform identifer and we use >>> the same algorithm to provide the same value in this case (the code >>> doesn't build without a value and I don't want to pass a hardcoded >>> value). >> >> I saw the response but it still sems short-sighted on including part of >> the `uname -r` value but not the rest. > > Erm, what should I do in this case ? We can't really add a random value > here. I am just emulating the behaviour of the upstream build (without > hardcoding values). I guess I'm wondering though what sort of release values are used with other systems? Could it instead be based on something like (major # * 100) + (minor #?) >> What happens if we ever produce >> a SunOS 6.0? > > I hope you'll call it "Solaris" then and drop the SunOS part (yes, yes, > I know... SunOS = core OS, Solaris = whole product) ... :-) Solaris is a marketing name for Sun's branded distribution. The actual OS component is SunOS. :-) >>>> usr/src/lib/libcmd/common/mapfile-vers >>>> >>>> This is showing up only under "Old". Are you removing it? >>> >>> "mapfile-vers" should be in the libraries's base directory to avoid that >>> this may get lost during source updates. The common/ subdir should for >>> the upstream sources only (only exception is the additions to the demo >>> code and test suite (e.g. the test to watch over the getconf >>> compatibilty (usr/demo/ksh/tests/sun_solaris_getconf.sh)) ). >> >> I didn't explain my question well. Are you planning on moving >> usr/src/lib/libcmd/common/mapfile-vers to >> usr/src/lib/libcmd/mapfile-vers and updating the file? Perhaps this is >> a question for April since it's a Teamware operation. > > Erm, yes. I am following the suggestion of Roger Faulkner (if I recall > the name correctly) who suggested to put the files in the base > directory. At least the following libraries do it the same way (this is > from our B51 tree): Well if Roger has reviewed this and signed off on it, then I'm happy. :-) >>>> usr/src/lib/libshell/misc/buildksh93.ksh >>>> usr/src/lib/libshell/misc/buildksh93.readme >> Or is the script that's used to generate the files which are eventually >> *checked in* to ON? > > Right. Please read the script and look at the original AST build system > now it works - "buildksh93.ksh" does some "modifications" to the build > setup to make sure we find some features in libraries which are normally > not detected automatically and enforce things like XPG6/C99 to avoid the > limitations of a normal build (which both dramatically affects > performance and other details). > BTW: "perl" in OS/Net does the same - see > http://mail.opensolaris.org/pipermail/ksh93-integration-discuss/2007-February/002244.html Yes, and I'm not sure if for that reason Perl really belongs in ON either :-) but I understand you're following that precedent. >>>> usr/src/pkgdefs/SUNWcsu/prototype_sparc >>>> >>>> Lines 50-51 - What is the reason for shipping a 32-bit version >>>> on SPARC? Can ksh93 be used to read 32-bit core files or >>>> processes? :-) >>> >>> There are several reasons including: >>> - ksh93 supports (loadable) binary plugins which may itself rely on >>> other shared libraries which may not be available as 64bit versions. In >>> those cases a 32bit ksh93 is needed. I am waiting for a sponsor for >>> http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6474270 >>> ("isaexec and magical builds") (see request-sponsor queue) to make >>> "isaexec" adjustable for applications which need such a functionality >>> (via restricting the list of ISAs based on accept and/or reject filter >>> environment variables). >> >> So how does a SPARC user use ksh93 in that case? Do they code their >> scripts to use /usr/bin/sparcv7/ksh93 directly? > > No, the idea was to implement Sun-Bug #6474270 ("isaexec and magical > builds") and set an environment variable which tells isaexec which ISA > should be used. I was hoping to get this work done in parallel but > somehow the request is still waiting in the request-sponsor list (see > http://opensolaris.org/os/bug_reports/request_sponsor/) ... ;-( But that hasn't been implemented yet so it seems including the sparcv7 version at this time is premature. >> BTW, what is the API for creating those binary plugins? Is it an open >> API as covered by the PSARC case? > > Uhm... yes and no. The ksh93(1) manual page describes the usage but > doesn't go into all the details. Basically the prototype is > |b_<name_of_command>(int ac, char *av[], void *context);|. Simple > commands can work with that while more complex ones which depend on > modifying the shell's state have to access |context| (which is a > |Shell_t *|) and the libshell API which uses |Shell_t *| as arguments is > not ARC'ed. > >>> - We need libshell&co. around for future consumers like the various >>> tools currently wrapped in "alias.sh" (this includes things like >>> /usr/bin/test etc.), "shcomp" (shell script compiler), /usr/bin/sleep >>> (using a 64bit binary for this is IMO an overkill), /usr/bin/printf etc. >>> and obmitting the 32bit shell would not be wise in this case (for >>> example: how else can we test the libraries then ?). >> >> Yes, but those components are not part of this case, correct? > > Well, we heavily stripped the original ARC case to make the first > putback self-contained, e.g. it should not affect anything else except > adding ksh93+libraries (we even stripped "shcomp" since it would deliver > a new kernel module (to recognize compiled shell code (similar to > javaexec))) - but ARC 2006/550 specifies these files and the usage of > isaexec (from > http://www.opensolaris.org/os/community/arc/testbed/caselog/2006/550/onepager/): > -- snip -- > Interface Description > --------- ----------- > /usr/bin/ksh93 the korn shell > /usr/bin/pfksh93 profile shell > /usr/bin/rksh93 restricted shell > > which will be hard links to /usr/lib/isaexec; isaexec will execute > the corresponding 32-bit binary in /usr/bin/{sparcv7,i86} or > the 64-bit binary/usr/bin/{sparcv9,amd64}, depending on the > architecture. > The isaexec links will allow the 64-bit version of ksh93 > to be executed by default on 64-bit platforms. > -- snip -- > As I said this is done intentional, even on SPARC (Garret bickered > already about the use of isaexec... ;-( ) ... > ... you're not coming up with the argumentation that we have to remove > parts which are not in use yet and re-add them later with the part which > starts using it, right ? Actually, I am arguing for delivering what was specified in the two PSARC cases and nothing else at this time. It's not a huge thing delivering the 32-bit version on SPARC but it's unnecessary at this time. Personally, I would rather see just the 64-bit version delivered at this time (yes, using isaexec just as we do with many 64-bit only SPARC deliverables) and then deliver the 32-bit version when the new plugins arrive. dsc
