simoniz0r / deb2appimage

Build AppImages from deb packages on any distro with simple json configuration
MIT License
117 stars 14 forks source link

Same scope as pkg2appimage? #8

Closed probonopd closed 5 years ago

probonopd commented 5 years ago

Does it have the same scope as https://github.com/AppImage/pkg2appimage? Is there a need for two such tools?

E5ten commented 5 years ago

I'd say so, given how much more convenient it is to use deb2appimage, unlike pkg2appimage which is much more confusing.

simoniz0r commented 5 years ago

I wouldn't have created it if I thought your solution was workable.

simoniz0r commented 5 years ago

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.

probonopd commented 5 years ago

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.

simoniz0r commented 5 years ago

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.

probonopd commented 5 years ago

With the almost guaranteed result that the resulting AppImages will run on exactly one machine, the developer's...

probonopd commented 5 years ago

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.

simoniz0r commented 5 years ago

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?

simoniz0r commented 5 years ago

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.

simoniz0r commented 5 years ago

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.

simoniz0r commented 5 years ago

I feel like you haven't even read my documentation...

Build AppImages from deb packages on any distro with simple json configuration

probonopd commented 5 years ago

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
simoniz0r commented 5 years ago

Who cares about lines of code? I already have a working AppImage of VSCode which I am using right now.

simoniz0r commented 5 years ago

https://github.com/simoniz0r/deb2appimage/blob/master/json/vscode.json

probonopd commented 5 years ago

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
simoniz0r commented 5 years ago

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
probonopd commented 5 years ago

OK so we have basically made similar tools twice

simoniz0r commented 5 years ago

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.

simoniz0r commented 5 years ago

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.

simoniz0r commented 5 years ago

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.

simoniz0r commented 5 years ago

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.