Euphoria Ticket #849: Packages do not contain what they should contain

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

Type: Bug Report Severity: Normal Category: Distribution
Assigned To: unknown Status: Fixed, Please Confirm Reported Release: 4.0.5
Fixed in SVN #: View VCS: none Milestone: 4.0.6

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.

Matt Lewis said...

what does that mean?

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.

Search



Quick Links

User menu

Not signed in.

Misc Menu