Hi Scott, Why don't you remove the -exact Lockfile 1.0 from::TicketMaster namespace? It should then load the 1.1 by default and that's it?
Brice. On Sat, Mar 15, 2025 at 6:37 AM Scott Pitcher < [email protected]> wrote: > Hi, > > I'm having a little trouble loading a specific version of a package in my > Rivet based website. > > I have a package called Lockfile 1.0 which was originally part of the > website base code. That lives in a directory titled "3rdparty". During the > ChildInitScript (called "childboot.tcl") this directory is added to the > auto_path - > > namespace eval ::Website { > > variable website ; # Where all library and site configuration > is stored. > > try { > # > # Setup the library directories. > # > set website(basedir) [file dir [info script]] > set website(logdir) [file join $website(basedir) .. log] > set website(libdir) [file join $website(basedir) lib] > * set website(3rdpartydir) [file join $website(basedir) .. 3rdparty]* > set website(tmpdir) [file join $website(basedir) .. tmp] > > .............................................................................................. > # > # Set the path for loading tclIndex files. This is all we need and the > rest of the library > # will load. Any source directories in the website configuration > should be in > # website(SourceDirs) after content is loaded, and we'll set those > after. > # > lappend ::auto_path [file normalize $website(libdir)] > if {[file isdirectory $website(3rdpartydir)]} { > * lappend ::auto_path [file normalize $website(3rdpartydir)]* > } > > Further down this script calls the childinit.tcl which loads the website > content, opens data bases etc and three of those modules "package require > Lockfile" and away it goes and just works. > > Well it did, until I installed a Lockfile 1.1 package independently in > /usr/local/lib/tcltk. This was a more recent version and I was using it > with some other tools not related to the Rivet website. This library was > not completely compatible with the version sitting alongside the Rivet > website, but all good - I'd changed the version number to 1.1. > > Over on the website the incompatible library caused the Apache threads to > run at 50% CPU and it sat there and span its wheels. The old Lockfile > automatically waited but the new one doesn't so the database maintenance > threads were running as fast as the CPU would let them. The new 1.1 library > has a -wait option so as to act like the old version. > > So I thought easy - require Lockfile 1.0, and the package can be loaded > out of the 3rdparty directory like it did before - > > namespace eval ::TicketMaster { > > package require Thread > package require sha1 > package require -exact Lockfile 1.0 > > But no, now it fails with a complaint that it needs 1.0 but it has 1.1, > with the 1.1 being the package over in /usr/local...... > > Mar 15 21:11:53.414563 2025 childboot fatal (pid 4849) (sess init): > childinit failed: version conflict for package "Lockfile": have 1.1, need > exactly 1.0 > Mar 15 21:11:53.415053 2025 childboot fatal (pid 4849) (sess init): > errorInfo=version conflict for package "Lockfile": have 1.1, need exactly > 1.0 > while executing > "package require -exact Lockfile 1.0" > (in namespace eval "::TicketMaster" script line 6) > invoked from within > "namespace eval ::TicketMaster { > > > Now I tried a few things to get the 1.0 version to load and about the only > thing that worked was removing the 1.1 package from /usr/local/..... But I > discovered along the way that if I add a "package forget Lockfile" just > before the package require - > > namespace eval ::TicketMaster { > > package require Thread > package require sha1 > * package forget Lockfile* > package require -exact Lockfile 1.0 > > logDebug ticketmaster "[namespace current] Lockfile available=[package > versions Lockfile] \ > Lockfile loaded=[package require Lockfile]" > > It now loads the correct 1.0 package, but further more reports that both > 1.0 and 1.1 are available - > > Mar 15 21:19:02.296247 2025 ticketmaster debug (pid 5273) (sess init): > ::TicketMaster Lockfile available=1.0 1.1 Lockfile loaded=1.0 > > I'm using Lockfile package in several modules. I haven't tried to package > forget in each one yet and Im not sure how that would work. > > As a work around I may rename the package under 3rdparty with a > distinctive prefix like Local or 3rd or something. There are bits and > pieces of my rivet base website that might end up in stand alone packages > and they will be moved to the 3rdparty directory. But I certainly don't > want an independently installed newer version of a package on the system to > be loaded instead of the local package which is part of the rivet base. If > I specify -exact ... 1.0 then it should load that one. > > > Anyway, I'm not sure what I'm doing wrong. I'm adding the 3rdparty > directory to fairly early in the ChildInitScript. Initially only the > /usr/local/lib... 1.1 package is available. If I do a package forget ... > then both the 3rdparty 1.0 and the /usr/local 1.1 are available? > > > Kind regards, > > Scott > > > > > > > > -- > +-----------------------------------------------------------------------------+ > |...will make the wilderness a pool of water, the dry land springs of > water...| > +-----------------------------------------------------------------------------+ > | Scott Pitcher [email protected] > | > | +61-3-9008-5695 (B) SVP Technical Services > | > |PGP: https://gnupg.org/ ABN 79 220 496 603 > | > |KEY: https://pgp.mit.edu/pks/lookup?op=vindex&search=0xEDBE43639EFD884D > | > +-----------------------------------------------------------------------------+ > > DISCLAIMER: > The content of this email is confidential and strictly intended only for the > recipient(s) specified in the message. If you have received this message by > mistake it is strictly forbidden to keep this email in any form, electronic > or hard copy, or to share any part of it with any one else, without the prior, > written consent of the author. If you have received this message by mistake, > please let me know by replying to this email, and then destroy it and any > copies. > > SECURITY: > I prefer to send and receive confidential messages protected by PGP public > key encryption. If you are willing to or are interested in protecting our > email communication with PGP encryption, please refer to https://gnupg.org/. > >
