Followup to message 22.03.00 from Jonathan Cunningham (fwd) 
Author Message
 Followup to message 22.03.00 from Jonathan Cunningham (fwd)

I posted this on Saturday, but it looks like it hasn't got through to the
list, so here it is again (with apologies to anyone who gets it twice)

<snip>

Quote:

> When I made that point it was not intended to be a comment on the
> environment variables that are unique to poplog, but a comment on the
> notion of 'the linux way' of doing things, a notion which I think Andrew
> had brought up.

> And as I understand it the linux way of doing things (unlike Solaris,
> for instance???) is that for a complex new package all executables go in
> the same bin directory (e.g. /usr/local/bin/, all stuff to do with
> libraries go in the same lib directory e.g. /usr/local/lib/ or maybe
> /usr/X11/lib, all man files in /usr/local/man, etc.

> So that means that when you install a package you scatter files all over
> the place, and that makes it hard to have simultaneously a new and an
> old version of the package given that all the files have the same names
> in both.

That's largely correct - as I understand it (and I don't necessarily
understand it...) the idea is that you put files which people need to get
at in some pre-agreed (or rather pre-imposed) place, so that people know
where certain files will be.  IMHO, this is sometimes good (e.g. I
think 'lib' directories are for libraries that compiling programs will
need to link against, so you only have to check one directory for files to
include), and sometimes bad (e.g. you can't browse man directories)

That said, for a large package like Poplog, most of the 'internal' stuff
would go in /usr/foo or /usr/local/foo, with only the minority (man pages,
executables, config. files etc.) elsewhere.

Unfortunately, that's made more complex by the lack of an agreed standard
for which files go where - the "Linux Standards Base" has been promising a
solution to this for a couple of years now, and I've yet to see anything
concrete (the problem, as always, is that everyone agrees that there
should be one true way, and everyone agrees that their way is that way)

Also, Linux package managers (which is good enough for most things, but
far from great) tends to be: install == uninstall old + install new.  That
said, RPM (and others, for all I know) could easily be made to handle
multiple versions, but this was not its intention.

GCC provides support for installing many versions on one system:
http://www.*-*-*.com/

A few thoughts on multiple versions...

Right now, Linux is mostly being used in low-end servers (e.g. web
servers) and on desktops, but it's pushing up towards higher-end servers
(and paradoxically down towards mobile computers), so while in the short
term it's reasonable to consider Linux to mean desktop, it's probably
unwise to make long-term plans based on that assumption.

On the other hand, while Linux is still a mostly desktop phenomenon, we
can assume that users will probably only want one version of Poplog on
their system.

By definition, users that want to use a 'non-standard' (old, new,
or just different) version of a program are the exception rather than the
rule, and are probably prepared to put up with a bit of work
(e.g. editting a login script) to get what they want.  They're also less
likely to be the kind of people that read man pages.

At install time, package management programs will probably let you
install files, and run an arbitrary script, preferably
(probably necessarily) with no input from the user.  At un-install time,
you get another script and all of your files un-installed. That puts some
severe limits on what can be done (e.g. it'd be quite tough to edit a
.Xdefaults file, even if you assumed users didn't edit it directly at
all).  Solutions which require changing something for every new package
aren't possible under Linux.

A strange idea occurs to me: for an executable symbolic link something
like '/usr/bin/xved -> pop11', how is 'pop11' resolved?  I'm fairly sure
that non-executable links resolve to the relevant file in the same
directory, but if executables resolve as if they were a command on their
own, it might be possible to just `alias pop11 $new-poplog/pop/com/pop11`.
Alternatively, if (probably more likely) it's resolved using $path, this
at least means that we only need to insert one file (pop11) somewhere
earlier into $path.

Finally, is there (and if not, I think there should be) a
poplog_version (or similar) variable?  That would make it possible to
write a single set-up script that could handle multiple versions of
poplog.

        - Andrew



Fri, 13 Sep 2002 03:00:00 GMT  
 Followup to message 22.03.00 from Jonathan Cunningham (fwd)
Andrew writes (among other things):

Quote:
> ....
> A few thoughts on multiple versions...

> Right now, Linux is mostly being used in low-end servers (e.g. web
> servers) and on desktops, but it's pushing up towards higher-end servers
> (and paradoxically down towards mobile computers), so while in the short
> term it's reasonable to consider Linux to mean desktop, it's probably
> unwise to make long-term plans based on that assumption.

> On the other hand, while Linux is still a mostly desktop phenomenon, we
> can assume that users will probably only want one version of Poplog on
> their system.

If you had lived through several versions of Poplog you might be
less confident of that! Most of the time changes are introduced in
such a way that things are backward compatible. However occasionally
there are major changes that cause a number of things in user
programs to break, e.g. when the default for procedure input and
output locals was (rightly) changed to be lvars rather than vars.

When such changes occur you may want to keep the old version around
while you learn about the new version and check out and modify your
programs. Sometimes you may need to be able to check whether an
unsolved problem is due to the changed version, by running your code
in both the old and the new, to see if it still works in the old.

Or you may wish to compare sources or documentation.

But I agree that many users will wait till other more expert users
have confirmed that changing is a good idea and then they will do it
and without keeping two versions going even for a short time.

Quote:
> ...
> Finally, is there (and if not, I think there should be) a
> poplog_version (or similar) variable?  That would make it possible to
> write a single set-up script that could handle multiple versions of
> poplog.

It's a pop-11 variable, set in the file $popsrc/initial.p

        155300 -> pop_internal_version;

The value of popversion is derived from this (I am not sure where
or when):
    popversion =>
    ** (Version 15.53 Mon Jul 12 19:45:02 BST 1999)

It occurs to me that it might be preferable to have a file called
system_version in $popsys, containing the value to be given to
pop_internal_version when poplink is invoked.

Aaron



Sat, 14 Sep 2002 03:00:00 GMT  
 
 [ 3 post ] 

 Relevant Pages 

1. Forwarding message 22.03.00 from Jonathan Cunningham

2. Fw: FWD: from Jonathan Cunningham about Macintosh implementations

3. forwarding message from Jonathan Cunningham (with comments)

4. HEX$ { 00 01 -- 02 03 -- 04 }

5. cursor behaviour rmcobol 7.00.03

6. news-relayFrom: jlc@uk.co.bmtech (jlc (Jonathan Cunningham))

7. ANNOUNCE: GRIDPLUS 1.00.00 - A Grid Based Screen Building Tool For TCL/TK

8. (Fwd) MESSAGE ON PHONE SCAM (fwd)

9. F83 for SUNs (Part 22 of 22)

10. Ada News - Week Ending: December 22, 1995 - 95-12-22.txt [1/1]

11. Reuse News - Week Ending 22 September 1995 - 95-09-22.txt [1/1]

12. ActiveX followup message

 

 
Powered by phpBB® Forum Software