Closed probonopd closed 5 years ago
I'd say so, given how much more convenient it is to use deb2appimage, unlike pkg2appimage which is much more confusing.
I wouldn't have created it if I thought your solution was workable.
If I recall correctly, pkg2appimage
requires the user to be on a Debian based distro and adds repositories to the user's repository list in order to download packages. deb2appimage
works on any distro and downloads the deb packages from either Debian or Ubuntu's repositories using curl
.
I found adding repositories to be entirely unacceptable and the requiement to be on a Debian based distro completely unnecessary as deb packages are just fancy archives that can just be extracted to the AppDir of the AppImage.
How do you resolve dependencies of those debs? pkg2appimage doesn't add the repos to the system to do this (it works on a private directory), but it does currently use the system's apt-get.
I don't. That's up to the person packaging it as it should be. Trying to figure out what should be bundled automatically very frequently leads to problems that the user cannot resolve themselves. If the user can specify the deps entirely on their own, they can make the package work relatively easily with a bit of testing.
With the almost guaranteed result that the resulting AppImages will run on exactly one machine, the developer's...
I think the proper solution would be to get apt-get bundled, so that deb2appimage does not need to run on a Debian/Ubuntu system.
With the almost guaranteed result that the resulting AppImages will run on exactly one machine, the developer's...
Not at all true. I test AppImages I build with deb2appimage on openSUSE Tumbleweed. This is a vastly different system than where the deps are being pulled from.
pkg2appimage is much more likely to result in AppImages which only run on the system that they are built on as the person building them is most likely testing them on the same system the deps were pulled from. This does not ever have to be the case for deb2appimage.
What exactly is your point here? Why did you not bring these things up when I submitted deb2appimage?
I think the proper solution would be to get apt-get bundled, so that deb2appimage does not need to run on a Debian/Ubuntu system.
No. Never. curl works great. Extracting the debs works great. deb2appimage works much nicer than pkg2appimage.
Also, what??? deb2appimage does not require to be ran on a Debian based system. That is your thing. deb2appimage can run on any Linux distro, AFAIK. As said above, I use it on openSUSE Tumbleweed without issues.
The AppImage for deb2appimage includes binutils so that debs can be extracted on any Linux distro and jq so that it can parse the config files without needing that installed. curl
is the only external dep, and that is available on every Linux distro that I'm aware of and installed by pretty much anyone using git. It's not bundled due to issues discussed in #7.
If you want to bundle apt-get in pkg2appimage, be my guest. I will not be doing that. There is absolutely no reason to do so. If you want to read the deps from the debs, they are stored in plain text that could very easily be parsed without apt-get (which would also require dpkg and all of its deps).
I personally don't find that to be necessary. Debian and Ubuntu list the deps on their websites in a nice format that is very easy to read. Users have had very little trouble asembling AppImages with deb2appimage.
I feel like you haven't even read my documentation...
Build AppImages from deb packages on any distro with simple json configuration
Simple... I find yaml simple, but I guess it's a matter of preference. I challenge you to produce a complete AppImage of Visual Studio Code in less lines of code:
app: VSCode
ingredients:
package: code
dist: trusty
sources:
- deb http://archive.ubuntu.com/ubuntu/ trusty main universe
script:
- wget -c --trust-server-names "https://vscode-update.azurewebsites.net/latest/linux-deb-x64/stable"
- ls code_*.deb | cut -d _ -f 2 > VERSION
script:
- cp usr/share/applications/code.desktop .
- cp usr/share/pixmaps/code.png .
- convert code.png -resize 512x512 usr/share/icons/hicolor/512x512/apps/code.png
Who cares about lines of code? I already have a working AppImage of VSCode which I am using right now.
Interesting. I'd be interested to compare the ingredients to see if you have caught all dependencies... how large is yours?
me@host:~/AppDir$ ls -lh /isodevice/Applications/Visual_Studio_Code-1.30.1-1545156774.glibc2.17-x86_64.AppImage
-rwxr-xr-x 1 root root 68M Dec 22 12:39 /isodevice/Applications/Visual_Studio_Code-1.30.1-1545156774.glibc2.17-x86_64.AppImage
I have all of the deps. It works perfectly fine on openSUSE Tumbleweed which is a vastly different system than where the deb comes from.
65M ./bin/vscode
OK so we have basically made similar tools twice
Nope. Mine is much more sane to use and works on any distro. If you don't have a point, I'd like to ask you to stop.
You also brought this up when I submitted deb2appimage to AppImageHub, IIRC, and I was able to submit it anyways. I don't understand what you are doing here now, months after I submitted it, bringing up these issues.
Also, this:
{"buildinfo":[{"prerun":["curl -sSL -o ~/.cache/deb2appimage/debs/vscode.deb 'https://go.microsoft.com/fwlink/?LinkID=760868'"],"name":"vscode","version":"latest","deps":"libnss3,libxkbfile1,libgconf-2-4,libnotify4","repoarch":"amd64","distrorepo":"Debian","repoversion":"stretch","binarypath":"/usr/share/code/code","desktoppath":"/usr/share/applications/code.desktop","iconpath":"/usr/share/code/resources/app/resources/linux/code.png","usewrapper":"true","postrun":[null]}],"apprunconf":[{"setpath":"false","setlibpath":"true","setpythonpath":"false","setpythonhome":"false","setpythondontwritebytecode":"false","setxdgdatadirs":"false","setperllib":"false","setgsettingsschemadir":"false","setqtpluginpath":"false","exec":"/usr/share/code/code.wrapper"}],"authors":[{"type":"Author","author":"Microsoft","url":"https://code.visualstudio.com/"},{"type":"AppImage Maintainer","author":"simonizor","url":"http://www.simonizor.net"}]}
I think I win.
Seeing as you created 2 entirely pointless issues, both of which suggest that you didn't even look at my repo one time for a second, I've blocked you from interacting with any of my repositories. I have no need for stuff like this in my life.
Does it have the same scope as https://github.com/AppImage/pkg2appimage? Is there a need for two such tools?