Euphoria
Ticket #849:
Packages do not contain what they should contain
-
Reported by
SDPringle
Feb 14, 2013
The various packages for non-Windows systems do not include everything that comes with the basic Windows Euphoria package. Among the non-Windows the packages do not provide the same things. Not even among the Linux distributions.
We can resolve most of the problems by making the package creation script for each package to direct make to install everything to some empty file structure, then copy also eudoc, and creole in the script. Here we offload most of the problem to the Makefile instead of several package creation scripts.
The docs say binaries go in /usr/bin but "utilities" go in /usr/share/euphoria/bin. We should instead install nothing in /usr/share/euphoria/bin and everything in /usr/bin. That's the UNIX way of doing things.
Scripts should use hg clone to create a 'clean branch' like in the Windows creation script to avoid including anything that doesn't belong.
Details
1. Comment by SDPringle
Feb 14, 2013
Part of this issue was discussed on the list: Debian stores euphoria.pdf.gz instead of euphoria.pdf. This is due to the way Debian packages things. Other distros store euphoria.pdf uncompressed.
2. Comment by jimcbrown
Feb 14, 2013
Not sure if it is possible to make them identical. Different distros understandably have different standards for where packages should store things, and in theory could require different formats (e.g. DistoA requires docs in PDF format, DistoB requires docs in Tex).
3. Comment by mattlewis
Feb 14, 2013
What's missing? Which scripts / makefiles don't use a clean export?
I'm still against including creole and eudoc in the euphoria distribution. I don't think they should be in the distribution for any platform.
4. Comment by SDPringle
Feb 14, 2013
Look in packaging and source/Makefile.gnu. Whereas eu.a and eudbg.a goes into /usr/bin in the unix package it goes into /usr/lib when you use make install. Now, Archlinux doesn't seem to install any docs. The Debian package system is really complicated. I hope others will investigate this as well.
5. Comment by mattlewis
Feb 14, 2013
That's odd (about eu.a and eudbg.a), because the debian packaging uses the makefile's install target to figure out what goes where. From packaging/debian/rules:
$(MAKE) DESTDIR=$(CURDIR)/debian/euphoria install install-docs install-tools
6. Comment by SDPringle
Feb 14, 2013
Not odd at all. Whichever allow call 'make install install-tools install-docs' to determine where things will go, will inherit from Makefile.gnu the locations for the install. So since the make target puts *.a into /usr/lib and scripts for the Debian and Slackware packages both let the Makefile decide where to put things, it follows that the three will install things to the same location. Except for the oddity of Debian always compressing PDF files, Debian works just right then given that eudoc and creole are to be excluded. There are also scripts packaging directories 'archlinux', 'unix' and 'source' should be looked at. The script for Arch Linux seems to be missing the docs install.
7. Comment by mattlewis
Feb 15, 2013
I haven't really looked at the Arch stuff, but the unix and source give the "traditional" euphoria directory tree. There is no /usr and no lib dir, so bin is the only place that makes sense.
The most important thing is that we're generating a correct eu.cfg file so that things are pulled from the right place.
8. Comment by SDPringle
Feb 15, 2013
The unix packaging should be unix style ofcourse.
9. Comment by mattlewis
Feb 15, 2013
said...
The unix packaging should be unix style ofcourse.
What does that mean?
10. Comment by jimcbrown
Feb 15, 2013
LSB? FreeDesktop? SVR4? BSD? The Open Group?
AFAIK there's not one standard for Linux/GNU distros, let alone the whole cacophony that is the whole of nixland...
11. Comment by SDPringle
Feb 16, 2013
Shawn Pringle said...
The unix packaging should be unix style ofcourse.
Jim Brown said...
LSB? FreeDesktop? SVR4? BSD? The Open Group?
AFAIK there's not one standard for Linux/GNU distros, let alone the whole cacophony that is the whole of nixland...
Please see section 2.2 of the 4.0 manual. RTFM: Read The Fine Manual.
12. Comment by jimcbrown
Feb 16, 2013
Section 2.2 of the 4.0 manual confirms my point - there is not a single standard for the Linux/GNU distros, let alone all the nixes out there. That section actually lists two separate standards: one for Linux/Unix in general, and one specifically for Debian.
13. Comment by SDPringle
Feb 16, 2013
Yes, it does say "Debian", but it doesn't mention the other OSes by name and install the way Windows does. It is ambiguous, it seems to me it is most natural that UNIX like OSes would be similar to Debian rather than Windows. So, if there is more than one standard for where things should go, remember what Tanenbaum said:
A.S. Tanenbaum said...
The best thing about standards is that there are so many to choose from.
14. Comment by jimcbrown
Feb 16, 2013
So you're saying that we should drop the other "generic" Linux/Unix standard, and use the Debian one in all of nixland?
15. Comment by SDPringle
Feb 17, 2013
It is not the common for packages to require you to add to the PATH environment variable. Instead the binaries install to /usr/bin, so I see the "Debian" one as the only UNIX style one in the documentation.
16. Comment by jimcbrown
Feb 17, 2013
I disagree. It's very common - when a user installs a program via configure make make install into a location in that user's home directory. Rarer these days, but there are still multi-user systems out there which are used by many users who have only normal user accounts but no root permissions. (Yes, even Linux/GNU systems - I used one of them.)
17. Comment by rkdavis
Feb 17, 2013
if you are building & installing yourself from source the two most common (and the most sensible imho from a maint. point of view) are /usr/local/{bin, share, etc, lib, include} for global usage & somewhere in the users home dir for personal use. Whenever possible if I install something using a package manager and the thing i'm installing is not something that isn't necessary for operation & doesn't already install into /usr/local then i'll try to move/install it into /usr/local
18. Comment by SDPringle
Feb 18, 2013
Well, rkdavis is right. We should install to the local tree until it becomes part of the official distribution. As for source and unix I guess we can use the Windows style install except into $HOME/ instead of C:\Program Files.
19. Comment by mattlewis
Feb 19, 2013
Shawn, I think you misread his comment. When you get, for example, a debian package, it should install to /usr, because it's installing through the package manager, even though it didn't come through the distro's official repo. This is the desired behavior, and you can add any repo you want. For example, I have google's chrome and opera's debian repositories added to my machine.
OTOH, when you run "make install" we install correctly to /usr/local, because /usr/local is meant as a place for the system administrator to install software. We don't have a quick and easy way to install a tree to the home directory directly from the main makefile, and I'm not sure we need to. We do have the ability to tar up such a thing in packaging/unix/Makefile. But installing there requires updates to the user's PATH, and I'm not sure we want to go down that hole.
20. Comment by rkdavis
Feb 19, 2013
i happen to prefer /usr/local & my home dir for anything that isn't part of the base distro as I think it's easier to handle updates & switching between prebuilt binaries and self built stuff. but most package managers install to /usr & unless it's part of the base system i try to move it if it's not a tangled mess with hardcoded paths.
I could brig up /opt but i'm sure someone would bludgeon me to death :)
one thing that would make the discussion about location of stuff a bit moot would be if eu.cfg could handle $HOME or "/" i was trying to make a tarball of my directory for someone who wanted to take a look but knows nothing about euphroia at the moment and I couldn't just create a generic eu.cfg that woud just work for them as / doesn't work so i had to also tell them to edit eu.cfg which isnt a big problem but it wasn't just untar and go
21. Comment by mattlewis
Feb 19, 2013
To make a tarball, you just have to build all of your binaries, then go into packaging/unix in the source tree and do "make". I think that relative paths work in eu.cfg. I know that you can use "~", which expands to $HOME.
We haven't put in the effort to get an automated way to have multiple versions installed. I have various 4.0 versions in my home dir, and I have symlinks in /bin (with /bin in my PATH) like eui405 that go to the 4.0.5 eui, etc, and appropriate eu.cfgs. Then I have some recent struct branch binaries installed to /usr/local.
22. Comment by rkdavis
Feb 19, 2013
ok i tried last night using ~ and it errored, i'll give it another go, probably a glitch on my end then.
23. Comment by SDPringle
Feb 20, 2013
See 2.3 of the 4.0.5 docs: If you are installing to home, you should use $HOME/.eu.cfg as the location of the eu.cfg file. Replace /usr with $HOME : make PREFIX=$HOME install
24. Comment by SDPringle
Feb 20, 2013
Can we agree in distro packages that *.a should go into /usr/lib? Can we agree that we don't need /usr/share/euphoria/bin?
25. Comment by mattlewis
Feb 20, 2013
I agree that the static libs should go into /usr/lib.
Do we really want to put all of the "bin" stuff into /usr/bin? We'll need to add shebangs and mark them executable.
26. Comment by rkdavis
Feb 20, 2013
going slighty OT here but the location of eu.cfg is not what I want to do. what i want to do is have an eu.cfg that I can use and I can have in the tarball of binaries that I send to people that looks like this.
[all] -d E32 -eudir /home/ukscone/euphoria -i /home/ukscone/euphoria/include [translate] -gcc -con -com $HOME/euphoria -lib-pic $HOME/euphoria/source/build/euso.a -lib /euphoria/source/build/eu.a [bind] -eub /euphoria/source/build/eub
which doesn't seem to work (at least I can't get it working)
e.g. $HOME or / is evaluated at runtime not build time
27. Comment by mattlewis
Feb 20, 2013
For tarball distributions, a path relative to the eu.cfg is what we want, but it doesn't evaluate that way. We should probably put in a new ticket for that behavior.
28. Comment by mattlewis
Feb 20, 2013
See ticket:851 for relative path enhancements for eu.cfg.
29. Comment by SDPringle
Feb 21, 2013
If you bury the dot-ex files into /usr/share, you wont even be able to call them using the interpreter without specifying the whole path into this share tree.
Shawn@Joy-PC /c/Users/Shawn/Documents/development/hg/4.0/packaging
$ dir ed.ex
dir: ed.ex: No such file or directory
Shawn@Joy-PC /c/Users/Shawn/Documents/development/hg/4.0/packaging
$ eui ed.ex
file name:
On the other hand:
$ export EUBIN=`which eui.exe`
Shawn@Joy-PC /c/Users/Shawn/Documents/development/hg/4.0/packaging
$ export PATH=
Shawn@Joy-PC /c/Users/Shawn/Documents/development/hg/4.0/packaging
$ $EUBIN ed.ex
sh: /c/Program: No such file or directory
Shawn@Joy-PC /c/Users/Shawn/Documents/development/hg/4.0/packaging
$ "$EUBIN" ed.ex
Can't open 'ed.ex'
Shawn@Joy-PC /c/Users/Shawn/Documents/development/hg/4.0/packaging
You don't need to run ed.ex with a shebang. The interpreter searches PATH for you. So, lets put it in the PATH: /usr/bin.
30. Comment by mattlewis
Feb 21, 2013
That's fine (allowing the interpreter to search the path), but if we're putting things in there, they should be executable, which means marking them executable and putting in a shebang.
31. Comment by mattlewis
Mar 01, 2013
Maybe some of the things we put in bin should be moved to demos.
32. Comment by SDPringle
Mar 07, 2013
Given the usefulness of both eudoc and creole in creating the documentation and that it is an 'included tool' in the EUPHORIA docs themselves. Keeping them out of Linux and making things consistent means changing Windows packages and the docs. We really ought to keep things like Windows is now, at least for the maintenance releases: 4.0.
33. Comment by SDPringle
Mar 13, 2013
See: hg:euphoria/rev/bec7ed43ed9f
changeset: 6046:bec7ed43ed9f branch: 4.0 tag: tip user: Shawn Pringle <shawn.pringle@gmail.com> date: Wed Mar 13 10:47:32 2013 -0300 files: packaging/archlinux/mkPKGBUILD.ex source/Makefile.gnu description:
- moving utility programs into /usr/bin
- ticket 849
34. Comment by SDPringle
Sep 16, 2015
Installing from the Debian file for Euphoria 4.0.5/i386 leaves you with documentation pages without the javascripts properly prepared.
Look at the directory in here /usr/share/doc/euphoria/html/js/. Script files are left compressed in the directory.