Ticket #68 (closed bug: fixed)

Opened 16 years ago

Last modified 15 years ago

DESTDIR support for packagers

Reported by: slack Assigned to: arnonym
Priority: major Milestone: FFADO 2.0
Component: Version:
Keywords: Cc:
The device the bug applies to:


Sorry for creating another ticket with priority "critical", but my intention is to avoid moving ffado in the wrong direction in this area (As in Ticket #67).

After some years of manually compiling and installing a lot of packages from source, and also building my own packages from many of them, I hope to know roughly how this should work.

1) Compiling, then installing by a normal user:

This user does not know much about the software, he often only wants to install and then use it.

It is very important here that the default directory is /usr/local, because otherwise this user will slowly "destroy" his system by overwriting already installed files in /usr.

ffado here already does it right.

2) Configuring, compiling, then installing by an advanced user:

This user knows what he wants, he reconfigures the software, then compiles und directly installs the software.

This is the user which often changes the installation location and also other things to match his system better.

This user also has no problem with the default location since he normally changes this and other a lot more advanced settings.

ffado here also does it right.

3) Configuring, compiling, then MAKING A PACKAGE, NOT DIRECTLY INSTALLING by a packager:

This is normally not the user who wants to install and use the software directly after the package is compiled.

Configuring and compiling is the same as in the second case, but the installation in the configured location is NOT wanted.

This user wants an installation option called DESTDIR which simply is a prefix which is only used while installing the files. DESTDIR does not change the content of any installed files at all.

If DESTDIR is "/tmp/pkg-ffado" and PREFIX is "/usr" then the whole software will be installed under "/tmp/pkg-ffado/usr".

The packages is happy because his system remains clean, and he can easily build this package by collecting all the files in "/tmp/pkg-ffado".

IMHO ffado does NOT YET support DESTDIR!

Note: Packagers in this case can't use "scons install", but have to manually copy all the files before packaging them.

So, DESTDIR is the important missing piece for "packagers".


pythondir_destdir_fix.diff (0.8 kB) - added by slack on 01/19/08 10:12:57.
libffado.pc.in-fix.diff (361 bytes) - added by slack on 01/20/08 03:51:14.

Change History

01/14/08 15:54:15 changed by jwoithe

For what it's worth I agree with what the ticket initiator says. The default location for something like ffado should be /usr/local/ since this is where user-installed software should in general go. Package maintainers know how to change this to /usr if they wish. Therefore I see no reason to change the default install location - it should remain as /usr/local/.

I also agree that DESTDIR support should be added - as the ticket initiator says, it makes life much easier for package maintainers who, when making packages, almost always want to deposit the package contents into somewhere other than their final resting place. For one, it means one doesn't have to extract the package contents out of directories populated by things other than the package being constructed.

01/15/08 11:28:25 changed by arnonym

  • owner set to arnonym.
  • status changed from new to assigned.

hehe, lets discuss things. :-)

Actually DESTDIR was on my roadmap for rather long time, but ppalmers told e that that is not important. so it kind of fell off of my list.

I will think about this the next days...

01/15/08 11:30:20 changed by arnonym

  • summary changed from ffado needs DESTDIR support, PREFIX default location is ok to DESTDIR support for packagers.

ah. and change the title. We don't have to fight these wars in the bug-list...

01/15/08 23:48:28 changed by jw

One more vote for the DESTDIR support from a package maintainer. Software which is simple to package usually makes it much faster to the official package repositories of linux distributions, and DESTDIR support is central to easy packaging :-).

01/16/08 13:10:11 changed by slack

@arnonym: The title change is also ok for me. It was never my intention to sound offending.

By the way, "ardour" also uses scons and they seem to support "scons DESTDIR=/my_path install".

By looking into its buildscripts we probably could get some useful hints.

Good look

01/16/08 15:12:44 changed by slack

Hopefully not too far off topic, but I could not resist to post this!

On sourceforge I found a very small project "glosung".

The scons scripts are very simple and implement just two options PREFIX and DESTDIR.

For me they give a very clean example of how this could be implemented, and a spec file using DESTDIR is also available.

P.S.: I have noticed the incorrect default value of PREFIX, but this can easily be changed and does not reduce the value of the example.

01/17/08 02:05:59 changed by arnonym

One question arises here:

How to handle .desktop files? xdg-desktop-menu doesn't seem to handle DESTDIR or something like that. Can I skip the desktop-files if DESTDIR is set and trust the packagers to do the right thing?

01/17/08 02:11:02 changed by arnonym

Would it even make sense to put all the desktop files and their icons into one distinct directory so the packagers can find and handle them separately?

01/17/08 03:08:56 changed by arnonym

Question to the packagers: Is r854 a step in the right direction?

01/17/08 12:45:23 changed by slack

Desktop integration is a very difficult thing, mainly because every distribution does it a little bit different.

I would suggest to avoid to do something special because it is impossible do get it right for everyone. And in a package creation script it is normally not much work to install desktop-files and icons.

For me it will be good enough to find the .desktop files and icons in a common directory e.g. called "xdg".

If you really want to place the .desktop file and the icons somewhere then I have often seen the following locations:

desktop-file: '$DESTDIR/share/applications/'

icons: '$DESTDIR/share/pixmaps/'

It will be helpful if the final application and icon paths are resolved, this could be done in the same way as in "ffadomixer.in" -> "ffadomixer".

Really important on the other side is to call tools like ldconfig or xdg-desktop-menu only when DESTDIR is not set, and the scons script has to check for every single tool it wants to use.

For example on my system xdg-desktop-menu doesn't exist but there is another similar tool called update-desktop-database.

Hope this helps

01/17/08 13:02:51 changed by arnonym

  • priority changed from critical to major.

Okay. I didn't mean to "install" icons or desktop-files to a certain location. Just put them in a distinct dir in the repository/tarball. :-)

So I will move the desktop-file (and future icons) to a dir called xdg and let packagers handle install of that. Only when no DESTDIR is used and the right tools are available, the desktop-files and -icons will be installed.

BTW: Downgrading the severity as the first commits of DESTDIR are in the repo. ;-)

01/19/08 10:12:12 changed by slack

None of the python mixer scripts in "$PYTHONDIR" are installed when DESTDIR is used.

Here is a patch to fix this problem.

01/19/08 10:12:57 changed by slack

  • attachment pythondir_destdir_fix.diff added.

01/19/08 11:51:11 changed by arnonym

@slack: thanks. r861 has it...

01/20/08 03:50:25 changed by slack

Sorry, found another DESTDIR bug, this time in libffado.pc.in :-)

The change of all the location variables in the scons-script to uppercase was missing.

And we now need to escape all other lowercase macros to avoid replacing it with our DESTDIR paths.


While I was working on this rather simple problem, I noticed that we are generating the libffado.pc file in a "non-standard" way.

Normally, the variable "prefix" is defined first and then all other variables are using this to define all other locations relative to "prefix".

If I understand it correctly, our scons scripts don't retain this relative information and so is not possible to generate libffado.pc in a similar way.

On the other side I have not found any strict requirements that one must use relative paths, so it is probably ok to let everything as it is now.

01/20/08 03:51:14 changed by slack

  • attachment libffado.pc.in-fix.diff added.

01/20/08 04:59:30 changed by arnonym

Will fix the pkgconfig issue. Actually I think our way of creating the file (or its paths) is correct. Even with auto* you have the possibility to define the bindir to be something not under prefix. You can do so too with our scons system. And if you can define [bin|lib|include]dir to any value you want, you also have to use these variables in the pkgconfig file instead of building them from prefix/<stuff>...

04/26/08 14:05:32 changed by arnonym

  • status changed from assigned to closed.
  • resolution set to fixed.

Question to the packagers: Is the current support of DESTDIR good for releases?

If not, please re-open this bug...