On Sat, 9 Oct 2004, Brent Fulgham wrote:
> Incidentally, I noticed that the current package does not insist that
> 'csh' be installed, which can cause an error during installation. I
> have updated the package to correct this problem.
I would like to find a way to remove the dependency on csh. I think
this requires digging into the files in $popsrc/syscomp that are
responsible for generating the script
$popsys/poplink_cmnd
which uses csh. I did once try to work out where exactly the csh
requirement originated in the poplog sources, but was too busy and had
to give up.
As far as I know that's the only point at which csh (or tcsh) is
required.
> Are there any plans to update Poplog from the current 15.53e release?
I hope this will happen, but at present it depends on me being able to
find time.
> If so, it would be wonderful to adjust some of the structure of the file
> system to match the Linux "File System Standard".
I've never heard of it before now. Google pointed me at this:
http://www.linuxjournal.com/article.php?sid=1104
I'll read it when I have time: is that the definitive specification?
One thing some people want to have as a standard is specific locations
for different parts of a package.
My objection to that is that it rules out having different versions of
the same package running on the same machine or shared network, e.g.
an old version, a current version and a new version. I have often
found this useful. E.g. in our departmental network we find it use to
have current and new versions of openoffice, mozilla, firefox, and of
course poplog when a new version of the latter is available for testing.
As far as I know all the linux 'package' mechanisms make this
impossible. As far as I am concerned that means that the package
mechanisms are wrong because they fail to address the complexity of
software engineering and the multiple requirements of different users of
the same system. These issues don't arise so much on purely personal
machines, though even on my personal machine I liked to keep old and new
versions running so that if a new version does not work I can quickly
go back to the old one. (E.g. when testing nightly builds of firefox,
or new versions of openoffice, as well as versions of poplog.)
(We had a seminar speaker from IBM yesterday talking about some new
software engineering standards requirements currently being discussed,
and this was an issue they had not thought about. But the speaker
instantly recognised the importance of this, and recognised it as a
serious omission.)
Apologies if the file system standard already takes account of this
need.
The need for agreed file structure for the poplog system sources etc
has partly been discussed on the poplog-dev list (anyone can subscribe
via majordomo@cs.bham.ac.uk in the usual way) in connection with the
work on upgrading windows poplog
http://www.cs.bham.ac.uk/research/poplog/openpoplog.html
But the people working on that are too busy earning their living as
software engineers for progress to be rapid.
There is also a port to OSX in progress now (initiated and led by Luc
Beaudoin, in Canada), and that also exacerbates the need for
rationalisation.
Because poplog compiles itself (mostly) and has different components
that are architecture specific and components that are operating system
specific, some of them relevant only at run time, others relevant when
the system is being rebuilt, the requirements for convenient managent of
all the combinations are more complex than in the case where it's all
written in a language for which a compiler can be assumed to exist on
all required platforms.
Thanks for all your help.
Aaron
|