28 Aug
2009
28 Aug
'09
6:51 p.m.
On Fri, Aug 28, 2009 at 03:31:53AM +0200, hollunder(a)gmx.at wrote:
It will never be run from there, the user is the
packager in the sense
that the user runs the script and thus creates the package that he can
install afterwards. We, as packagers, just write a part of the script,
the user can modify this script to her liking or just run it, which in
turn builds the binaries and creates the package on the users system.
Sorry if we were unclear about that, but we were talking about AUR,
the arch user repository where only scripts are supplied that help the
user to build a package. AUR doesn't provide binaries as such (except
for rare cases). The same scripts are used for the official
repositories but there they provide binaries and the scripts are
optional.
I hope it's somewhat clearer now, sorry for the confusion.
Yes, thanks.
I'm perfectly willing to prefix $(DESTDIR) to any install directories
if that is all that's required.
But while I can clearly see the use and even necessity for $DESTIR
for someone who is creating a binary package from a source package
(without having to really install that package locally), what on
earth is the purpose of forcing someone who installs from source
to go via such an intermediate step ? If the Makefile provides a
working 'make install' why complicate it ? And more pertinently,
how am I supposed to provide support for users who do such things ?
If I release a source package, and someone has a problem compiling
or installing it, I'd be happy to help. But not if the installation
procedure has been modified for no good reason - I could probably
go along with some changes, but where does that end ?
The web page about $DESTDIR you pointed says that one of the uses
would be to allow a user without root privileges to install in
some local dir (s)he has access to. But it contradicts that same
use by declaring that 'embedded file names will not be modified'.
Which in some cases will mean that the application will not run.
To install into a e.g. a home directory a user would have to modify
$PREFIX, not $DESTDIR.
Ciao,
--
FA
Io lo dico sempre: l'Italia è troppo stretta e lunga.
28 Aug
28 Aug
8:43 p.m.
New subject: Auto-wah plugin
Am Fri, 28. Aug 2009 um 22:50:50 +0200 schrieb Fons Adriaensen:
Hi Fons,
But while I can clearly see the use and even necessity
for $DESTIR
for someone who is creating a binary package from a source package
(without having to really install that package locally), what on
earth is the purpose of forcing someone who installs from source
to go via such an intermediate step ?
DESTDIR usage is only for building packages; there is no purpose for
someone bypassing his packaging system and installing it directly from
source to use this variable. But this procedure may be unhealthy.
If the Makefile provides a
working 'make install' why complicate it ? And more pertinently,
how am I supposed to provide support for users who do such things ?
I guess you are not. If I did not miss anything here, the only topic
was about "packaging". There it is a basic requirement, if the packager
likes to avoid patching the supplied Makefile.
If I release a source package, and someone has a
problem compiling
or installing it, I'd be happy to help. But not if the installation
procedure has been modified for no good reason - I could probably
go along with some changes, but where does that end ?
I guess there will be other people who will help out. So don't worry.
The web page about $DESTDIR you pointed says that one
of the uses
would be to allow a user without root privileges to install in
some local dir (s)he has access to. But it contradicts that same
use by declaring that 'embedded file names will not be modified'.
Which in some cases will mean that the application will not run.
May be, but this depends on the application using the supported
file(s). There may be applications allowing to load modules from
standardised user directories. But there must be some kind of
convention about the location.
$ cd
$ find . -name share
./.gnome2/share
./.local/share
./.kde/share
[...]
Seems not to be uncommon to use File System Hierarchy (FSH)
compatibility in home directories.
To install into a e.g. a home directory a user would
have to modify
$PREFIX, not $DESTDIR.
Depends on the convention.
Guido
--
http://www.bayernline.de/~gscholz/
http://www.lug-burghausen.org/
9:07 p.m.
New subject: Auto-wah plugin
Guido Scholz wrote:
DESTDIR usage is only for building packages; there is
no purpose for
someone bypassing his packaging system and installing it directly from
source to use this variable. But this procedure may be unhealthy.
DESTDIR is very useful for developers, too. It provides you with an easy
way to check your 'make install' target.
And it can be useful for end users as well. E.g., you might want to
first do a staged install to see what exactly gets installed and where.
(With simple packages, make -n install will give you that information,
but that's not generally true.) Also, I don't know how often I cursed at
a source package which provided no uninstall target; in that case a
staged install gives me the information I need to uninstall the package.
Source packages which provide neither DESTDIR nor 'make uninstall' can
be a royal pita to deal with, usually I won't touch them with a 5 foot
pole, except maybe on a "scratch" system that's hosed anyway.
So, DESTDIR is pretty much standard these days, it is easy to support
and makes developers, users *and* packagers happy, I think that every
source package should have it. :)
My 2c.
Albert
--
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email: Dr.Graef(a)t-online.de, ag(a)muwiinfa.geschichte.uni-mainz.de
WWW: http://www.musikinformatik.uni-mainz.de/ag
29 Aug
29 Aug
10:48 a.m.
New subject: Auto-wah plugin
On Fri, Aug 28, 2009 at 4:50 PM, Fons Adriaensen<fons(a)kokkinizita.net> wrote:
I'm perfectly willing to prefix $(DESTDIR) to any
install directories
if that is all that's required.
But while I can clearly see the use and even necessity for $DESTIR
for someone who is creating a binary package from a source package
(without having to really install that package locally), what on
earth is the purpose of forcing someone who installs from source
to go via such an intermediate step ? If the Makefile provides a
working 'make install' why complicate it ?
Fons - you don't! DESTDIR is empty by default. Hence "make install"
installs directly for a regular user who has not bothered to set it.
PREFIX is the way that a non-packaging user targets the install to
somewhere other than the default, no matter what "the web page about
DESTDIR says". DESTDIR is strictly for packagers/developers, and
merely has to be supported by the makefile, not used by a "regular
user".
The reason for having two distinct variables is that some software
needs to know PREFIX at compile time (e.g. where to find conf files,
or private shared libraries, etc). If the packager is aiming to
install the software in /foo/bar eventually, then she needs to set
PREFIX appropriately. But they may want to use /baz/bomb as a "staging
ground" for packaging, hence DESTDIR. Again, this does not affect
"regular users", who simple set PREFIX (if anything at all).
--p
1:13 p.m.
New subject: Auto-wah plugin
On Sat, Aug 29, 2009 at 08:48:27AM -0400, Paul Davis wrote:
Fons - you don't! DESTDIR is empty by default.
Hence "make install"
installs directly for a regular user who has not bothered to set it.
PREFIX is the way that a non-packaging user targets the install to
somewhere other than the default, no matter what "the web page about
DESTDIR says". DESTDIR is strictly for packagers/developers, and
merely has to be supported by the makefile, not used by a "regular
user".
The reason for having two distinct variables is that some software
needs to know PREFIX at compile time (e.g. where to find conf files,
or private shared libraries, etc). If the packager is aiming to
install the software in /foo/bar eventually, then she needs to set
PREFIX appropriately. But they may want to use /baz/bomb as a "staging
ground" for packaging, hence DESTDIR. Again, this does not affect
"regular users", who simple set PREFIX (if anything at all).
Yes, that is and already was very clear, but:
[Renato]
... but the fact is that in Arch
for building from source in a pacman-aware (pacman is Arch's package
manager) manner, you need the DESTDIR option... infact you first
install all the files with the exact same direcotry tree as would
do 'make install' but, instead of in root, in a working directory...
i.e. you do 'make DESTDIR=/pathtotmpdir install' ...
Which to me seems to mean that in Arch even users who install
from source are supposed (I never wrote 'forced') to do this.
Ciao,
--
FA
Io lo dico sempre: l'Italia è troppo stretta e lunga.
8:04 p.m.
New subject: Auto-wah plugin
On Sat, 29 Aug 2009 17:12:34 +0200
Fons Adriaensen <fons(a)kokkinizita.net> wrote:
On Sat, Aug 29, 2009 at 08:48:27AM -0400, Paul Davis
wrote:
I just didn't want to delve too deep into Arch's way of building from
source, so I was hasty and not precise.
As allready said, you really don't run these commands directly, but
rather from a script which you write your own but most commonly you
find on the AUR, allready written by someone else. The script runs the
command I posted above and then, if you
wish, you use pacman to actually install these files on the system.
Renato
Fons - you don't! DESTDIR is empty by
default. Hence "make install"
installs directly for a regular user who has not bothered to set it.
PREFIX is the way that a non-packaging user targets the install to
somewhere other than the default, no matter what "the web page about
DESTDIR says". DESTDIR is strictly for packagers/developers, and
merely has to be supported by the makefile, not used by a "regular
user".
The reason for having two distinct variables is that some software
needs to know PREFIX at compile time (e.g. where to find conf files,
or private shared libraries, etc). If the packager is aiming to
install the software in /foo/bar eventually, then she needs to set
PREFIX appropriately. But they may want to use /baz/bomb as a
"staging ground" for packaging, hence DESTDIR. Again, this does not
affect "regular users", who simple set PREFIX (if anything at all).
Yes, that is and already was very clear, but:
[Renato]
... but the fact is that in Arch
for building from source in a pacman-aware (pacman is Arch's package
manager) manner, you need the DESTDIR option... infact you first
install all the files with the exact same direcotry tree as would
do 'make install' but, instead of in root, in a working directory...
i.e. you do 'make DESTDIR=/pathtotmpdir install' ...
Which to me seems to mean that in Arch even users who install
from source are supposed (I never wrote 'forced') to do this.
30 Aug
30 Aug
6:32 p.m.
New subject: Auto-wah plugin
Uhmm..it's sort of becoming too much discussion over a simple variable. Why
bring in Arch in discussing $DESTDIR? There's nothing "deep" about
"Arch's
way of building". It does not have to be "DESTDIR", some developers only
define and call, say, "PREFIX", in the install rule and use it as a DESTDIR
while the actual prefix (/usr or /usr/local) is determined in other ways.
It's trivial to work around it when a developer does not have a DESTDIR
provision/equivalent, for instance: if you don't want to patch, just look at
the install rule and follow suit in your script (whether Pacman PKGBUILD or
Portage ebuild or Foobar goosebumps).
It isn't wise to push a distro's packaging shebang towards an upstream
developer. But yes, DESTDIR is good practice and most software have it or
something similar :) Nothing harmful.
29 Aug
29 Aug
3:23 p.m.
New subject: INVADA meter plugin and DSP load
Hi,
Just tried the invada LV2 meter plugin in ardour. Existing critics on the VU relevance
notwithstanding, there is an issue on the DSP load if the plugin is active (state of
virtual switch in the LV2 plugin window is Active) but the ardour transport is stopped.
If I turn the virtual switch off or deactivate the plugin the ardour way, DSP load goes
back to normal. When the plugin is chewing some data during active transport, the DSP load
is also OK.
Summary: stopped transport + active plugin = high DSP load.
Maybe this is already addressed or at least known ?
J.
3:37 p.m.
New subject: [off-list] INVADA meter plugin and DSP load
James Warden wrote:
[snip] Existing critics on the VU relevance
notwithstanding [snip]
Pardon, that some of us make noise because of this, me too. As a rule of
thumb, there's nothing wrong if you or any other person will use such a
meter. I'll react my own onesided opinion. Concepts needs to be
overstated sometimes ;).
3:38 p.m.
New subject: [off-list] INVADA meter plugin and DSP load
:D it should be off-list :D
Ralf Mardorf wrote:
James Warden wrote:
[snip] Existing critics on the VU relevance
notwithstanding [snip]
Pardon, that some of us make noise because of this, me too. As a rule
of thumb, there's nothing wrong if you or any other person will use
such a meter. I'll react my own onesided opinion. Concepts needs to be
overstated sometimes ;).
3:41 p.m.
New subject: INVADA meter plugin and DSP load
On Sat, Aug 29, 2009 at 10:23:45AM -0700, James Warden wrote:
Just tried the invada LV2 meter plugin in ardour.
Existing critics on the VU relevance notwithstanding, there is an issue on the DSP load if
the plugin is active (state of virtual switch in the LV2 plugin window is Active) but the
ardour transport is stopped.
If I turn the virtual switch off or deactivate the plugin the ardour way, DSP load goes
back to normal. When the plugin is chewing some data during active transport, the DSP load
is also OK.
Summary: stopped transport + active plugin = high DSP load.
Maybe this is already addressed or at least known ?
It has denormal issues, which are easy to correct.
--
FA
Io lo dico sempre: l'Italia è troppo stretta e lunga.
3:09 p.m.
New subject: Auto-wah plugin
On Friday, August 28, 2009, Fons Adriaensen wrote:
To install into a e.g. a home directory a user would
have to modify
$PREFIX, not $DESTDIR.
Unless he uses chroot(1) with $DESTDIR as argument, to test the program in an
isolated environment.
Without having to use chroot, I used to test my old KDE3 programs installed
with DESTDIR=$HOME/mytestroot and PREFIX=/usr (for instance). In this case, I
have to export KDEDIRS="${DESTDIR}${PREFIX}" before running the programs.
CMake build systems provide DESTDIR support OOB.
Regards,
Pedro
5559
days inactive
5561
days old
linux-audio-dev@lists.linuxaudio.org
11 comments
9 participants
participants (9)
-
Albert Graef -
Fons Adriaensen -
Guido Scholz -
James Warden -
Paul Davis -
Pedro Lopez-Cabanillas -
Ralf Mardorf -
Ray Rashif -
Renato