Some notes: (1) We should probably spell out "debian" since 'deb' is the J 'delete extra blanks' routine. Though, also, 'debian' implicitly now also refers to distributions like ubuntu and devuan
(2) This versioned package thing is typically handled in debian using virtual packages Overview: https://www.linuxtopia.org/online_books/linux_system_administration/debian_linux_guides/debian_linux_faq/ch-pkg_basics.en_007.html Gory details: https://www.debian.org/doc/debian-policy/ch-relationships.html#packages-which-break-other-packages-breaks and https://www.debian.org/doc/debian-policy/ch-relationships.html#virtual-packages-provides But, thinking about this, I'm not sure we need to go that far, yet (since there's no packages which depend on J, yet). The only source of contention would be the version-free name in /usr/bin/. Also, until J gets incorporated in a debian package archive, the overhead of installing two packages seems excessive. So... best of both worlds? /etc/alternatives/ to manage /usr/bin/ijconsole, create the "virtual package" (which doesn't install any thing, it's just an administrative artifice) -- https://debian-administration.org/article/91/Using_the_Debian_alternatives_system which means using https://manpages.debian.org/stretch/dpkg/update-alternatives.1.en.html (And, while we are here, I would recommend offering a /usr/bin/jlang in addition to /usr/bin/ijconsole. (I would also recommend adding a jlang windows and osx implementations which does basically the same thing. Though I haven't thought through the details far enough, the point here is both to leverage search engine equity and to provide a "universal" name that would allow developing J scripts which do not have to know discover where J is installed. This may be overly ambitious, as malware keeps forcing system changes, but the other alternative seems to be packaging a copy of J with J scripts if you want other people who are not developers to be able to use them. Open ended project, though, so this should *not* happen all at once.) Also, while we're at it, create a J debian repository (which is basically just a file that lists the J debian packages) so that users can install and maintain J packages using apt. This would be a cut down version of https://wiki.debian.org/DebianRepository specifically following the pattern described at https://wiki.debian.org/DebianRepository/SetupWithMinidinstall This is *untested*, but I think what I am describing would look like this: (*) Add to the debian 'control' file, in each existing J debian package, the line Provides: jlang (*) Remove from each existing J debian package the definition of /usr/bin/ijconsole (*) In each debian postinst package, add an update-alternatives line, something like this: update-alternatives --install /usr/bin/ijconsole ijconsole /usr/bin/ijconsole-9.01 901 --slave /usr/bin/jlang jlang /usr/bin/ijconsole-9.01 901 If we had man pages or some other such system artifact, those would be additional "slaves" to ijconsole. That should fix the package conflicts issues. If not, ... well... more discussion needed, maybe? To support apt, we need publically accessible files which can be referred to in /etc/apt/sources.list and which state where J packages can be pulled from. The important issues there are (1) cryptographically signing the packages, to minimize the security alerts that go off when other people install from a publically accessible system. This means getting a key signed by a public key signing entity, and (2) creating a top level file which states where the downloadable packages are located. I believe that the https://wiki.debian.org/DebianRepository/SetupWithMinidinstall instructions cover that issue. Finally, if J gets pulled into a distribution which a developer is using and they want to instead have their own dev repository override that, /etc/apt/preferences could be used to deal with that issue. That said, if anything I said here seems to raise insurmountable barriers (or, just, more research than can be completed in available time), please let me know or point me at how to reproduce the problem. All of these issues wind up seeming simple only after we get past the barriers. And, by their very nature, they require a certain amount of repetition before that point. ((The "once and only once" meme is ... a sometimes essential approach, but it can't be a universal. Minimization relies on standards, and standards get used frequently..)) Thanks, -- Raul On Sun, May 3, 2020 at 12:31 PM bill lam <[email protected]> wrote: > > Actually j807 and j901 can coexist but the deb package was written bad > enough. > > Anyways you need to install jqt with usual sudo ijconsole / pacman / > install'qtide' etc. > In case symlink of jqt not created, the executable is /usr/bin/jqt-9.01 > you can make symlink to /usr/bin/jqt or just run /usr/bin/jqt-9.01 > > > On Mon, May 4, 2020 at 12:20 AM Bill Harris <[email protected]> wrote: > > > I tried to install J9.01 over J8.07 on Debian Stretch following the Debian > > instructions, and I got > > > > root@here:/home/me/bin# dpkg -i j901_amd64.deb > > > (Reading database ... 366466 files and directories currently installed.) > > > Preparing to unpack j901_amd64.deb ... > > > Unpacking jlang (9.01) over (8.07) ... > > > dpkg: warning: unable to delete old directory > > > '/usr/share/j/8.07/addons/ide': Directory not empty > > > dpkg: warning: unable to delete old directory '/usr/share/j/8.07/addons': > > > Directory not empty > > > dpkg: warning: unable to delete old directory '/usr/share/j/8.07': > > > Directory not empty > > > Setting up jlang (9.01) ... > > > root@ here:/home/me/bin# exit > > > exit > > > > > > So you can't install in parallel anymore, it seems. > > > > I quit an open jqt 8.07 session, tried again, and it seemed to work. > > ijconsole must be using a previous alias, and it works: > > > > ~/bin$ ijconsole > > 9!:14 '' > > j901/j64/linux/release-c/commercial/www.jsoftware.com/2020-01-11T10:39:00 > > > > Then I followed the instructions to install all addons. At the end, it > > said, > > > > Done. > > Addons are up to date. > > Restart J to get the latest version of the base library. > > exit'' > > root@here:/home/me/bin# ijconsole > > 9!:14'' > > j901/j64/linux/release-c/commercial/www.jsoftware.com/2020-01-11T10:39:00 > > install 'base' > > Updating server catalog... > > > > exit'' > > > > Then i tried jqt: > > > > ~/bin$ jqt > > Load library libj.so.8.07 failed. > > me@here:~/bin$ ls -l /usr/bin/jqt > > lrwxrwxrwx 1 root root 21 May 7 2019 /usr/bin/jqt -> > > /etc/alternatives/jqt > > me@here:~/bin$ ls -l /etc/alternatives/jqt > > lrwxrwxrwx 1 root root 17 May 7 2019 /etc/alternatives/jqt -> > > /usr/bin/jqt-8.07 > > > > I'm not familiar with the /etc/alternatives hierarchy nor who writes to it > > (except 8.07 apparently did and 9.01 may not have). > > > > Any tips from this point? > > > > Thanks, > > > > Bill > > > > PS: I also tried jhs according to > > https://code.jsoftware.com/wiki/Guides/JHS/Install: > > > > ~/bin$ jhs > > bash: jhs: command not found > > > > Perhaps these problems are related? > > -- > > Bill Harris > > ---------------------------------------------------------------------- > > For information about J forums see http://www.jsoftware.com/forums.htm > > > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
