You are not logged in.
Hi,
I want to create a PKGBUILD for some software. I created all the necessary patches and build runs trhough just fine. However, when installing into the fake-root environment there seems to be some trouble. Most files get installed under fakeroot/$prefix, but some files are actually copied to fakeroot/$buildfolder . I think this is due to the fact, that some files get copied around as some subprojects are built.
How do I stop makepkg from copying these files? This crashes the installation since $buildfolder already exists.
Offline
I have no idea what you mean using "fakeroot" as a path, or what $prefix or $buildfolder mean. "Folder" isn't even the correct term on Linux.
Offline
Before the package gets compressed the root folder of the pkg (contains PKGBUILD) contains a folder named pkg. The path of that folder is the "fakeroot path". $prefix means the path of my installation prefix, in this case /opt. $buildfolder or let's say $buildpath is the path to the subfolder of the pkg root folder containing the build files.
Offline
OK, we need common terminology. Please check the PKGBUILD man page and use the terms found there.
Offline
Of course I'm willing to look up the 'correct' terminology. There are exactly three folders {src,pkg,start}dir in the manpage. There is an (obvious) one-to-one correspondence to my terminology.
That has nothing to do with my problem, though.
Offline
Since your posts are senseless, I have no idea what your problem is.
Offline
Sorry, your help is really appreciated. But I don't really understand which part you don't understand. To me, it all makes perfectly sense :\
Offline
There is an (obvious) one-to-one correspondence to my terminology.
To me, it all makes perfectly sense :\
It doesn't seem obvious to us - and it's also irrelevant whether it makes perfect sense to you, as long as it doesn't make sense to the people you're asking for help.
And more specifically: we can't quite get any useful information out of your posts. Most importantly, there is no PKGBUILD file (or any other concrete information that describes your situation).
A tip, though: try to strip down your PKGBUILD to a minimal "demo version" that still causes your issue, try to figure out what part in there could be the cause, and if you get stuck on that, ask here to clarification on that "demo PKGBUILD".
Last edited by ayekat (2016-10-18 09:59:24)
Offline
If it wouldn't make sense to me, then (!) it would be senseless. On the other hand, as long as it makes sense to me, it's hard to see where I can improve the explanation. Anyway, let's try again;)
I guess the crucial part of my PKGBUILD is that:
build() {
cd "$srcdir/$pkgname"
# patch_cmake
patch_python_version
mkdir -p build
cd build
../configure --prefix=/opt/prog
# make
}
}
package() {
cd "$srcdir/$pkgname/build"
make DESTDIR="$pkgdir/" install
}
You can see that make is commented out in the build function. The reason for that is, that the Makefile automatically invokes make install. Thus, running build() will try to copy files to /opt/prog, which fails due to non-sufficient rights.
I thought I have two options.
1) Ask the developers to fix their Makefile
or
2) try to move the build part to the package() function.
In the latter case I don't run into my first problem, because all the files copied by make install are installed under $pkgdir/$prefix (where $prefix = /opt/prog). However, $pkgdir contains 2 folders.
opt and home (home because $srcdir is a subsubfolder of home).
However, I don't want to have that second folder in my $pkgdir. I certainly understand, why this is happening. But before reverting back to option 1 I wanted to see, if there is any other approach.
Offline
Option 1 is the correct fix. It should be simple to patch it yourself in the meantime as well.
Offline
I agree, option 1 is the first way to go. However, it seems to be extremely complicated to fix. The main Makefile alone consists of 1200 lines of code. That's why am looking for another workaround.
Offline
Care to post a link to it? It shouldn't be difficult to tell it not to run the install target with the default target.
Offline
Even if it's 1200 lines of poorly written recipes with hardcoded paths, getting upstream to fix their shit is more valuable to the wider community, and reduces the workload on you as a package maintainer. Working around these sorts of problems in a PKGBUILD is fragile at best, and is only really suited to dead or slow-moving projects that you're willing to keep a close eye on.
Sakura:-
Mobo: MSI MAG X570S TORPEDO MAX // Processor: AMD Ryzen 9 5950X @4.9GHz // GFX: AMD Radeon RX 5700 XT // RAM: 32GB (4x 8GB) Corsair DDR4 (@ 3000MHz) // Storage: 1x 3TB HDD, 6x 1TB SSD, 2x 120GB SSD, 1x 275GB M2 SSD
Making lemonade from lemons since 2015.
Offline
@WorMzy: Good thoughts! Thanks.
Here is a link to the Makefile generated by automake: https://svn.jmodelica.org/branches/1.17.x/Makefile.in
Offline
That's a recursive setup, so we'd need to know just where it fails. The INSTALL file says that "make" should just build, though, so this is definitely a bug.
Offline