Add embedded tar script packager

[oyarzun]

Adds an embedded tar script packager.

• Installer run as normal user it defaults to ~/.local/appdir
• Installer run with sudo it defaults to /usr/local/appdir
• Install desktop file

[neilcsmith-net]

Thanks, interesting idea. Sorry for the delay. I've not got a lot of time for NetBeans things at the moment, but had a glance through. Few concerns, but nothing major.

We were discussing getting a first non-beta release out, which involves removing a few deprecated options first. Not sure if this should merge before or after that release.

I was wondering whether we could reduce duplication of some of these options by having some shared Linux options. That might require some thought given the current structure, and might not be worth the trouble. Depends if we might expect more Linux package types in future.

[oyarzun]

@neilcsmith-net Happy New Year!

Any more thoughts on this PR? Does it need more changes? It it worthwhile to be merged?

[neilcsmith-net]

@oyarzun Happy New Year to you too!

Apologies for delays in getting this in. I've been mostly out of the NetBeans loop for the last few months, and was hoping someone else might take a look at this as well in that time.

I think this would be nice to get in, but I'm not sure whether we should concentrate on releasing the existing master in non-beta form before merging new packagers? @mbien @ebarboni any thoughts?

I'll take another look to refresh myself on this as soon as I can, but I think all changes are OK as is. One thing I'd wondered about was abstracting some of the duplicate Linux options somehow, but that can probably be looked at after merging if at all.

[ebarboni]

Hi, I think it could be merged beta7 or 1.0.0 is a decision that can be done for release later.

[neilcsmith-net]

Thanks @ebarboni but I don't agree with you that the version can be decided later. If we want the next release to be 1.0.0 then we need to do that before this is merged.

[ebarboni]

Thanks @ebarboni but I don't agree with you that the version can be decided later. If we want the next release to be 1.0.0 then we need to do that before this is merged.

for me this is only if we don't want this PR for 1.0.0

but we can go for a vote thread to have current nbpackage released as 1.0.0

[neilcsmith-net]

for me this is only if we don't want this PR for 1.0.0

but we can go for a vote thread to have current nbpackage released as 1.0.0

Yes, I don't think we should merge this for 1.0.0 unless we plan on having more beta releases first (and personally I don't think we should do that). We had originally talked about stabilising the existing features and releasing 1.0.0. That needs a tidy up PR first to remove a few deprecated things. I will look at that next week, and aim to get a release vote started after that. Then we can merge this for the next release.

@oyarzun sorry for the delay and tangential discussion there.

[oyarzun]

@neilcsmith-net no problem. I agree with your thinking release 1.0.0 first.

[oyarzun]

@neilcsmith-net I've modified the PR to gzip the tar file. I've reverted the gzip changes since the tgz's were partially corrupt.

Let me know if there are any other changes needed.

[neilcsmith-net]

I'll do some further testing soon, and see if we can merge now that 1.0 is released. Would still appreciate another set of eyes on this - maybe @mbien or @homberghp have some thoughts?

[mbien]

Hi! Sorry for the delays.

1. Code looks great.

2. Tried a minimal setup to bundle NetBeans Deluxe Edition. For that I only set the name in the properties file, I think according to the comments in the config thats all what is needed as minimal setup.

bundle creation worked without warning, but on install on arch/gnome I got:

$ ./NB_Deluxe-1.0.noarch.sh 
Enter NB Deluxe Install Prefix [/home/virtual1/.local]/netbeans: mega
Installing NB Deluxe in mega/netbeans
/home/virtual1/.local/share/applications/netbeans.desktop: error: value "mega/netbeans/launcher/netbeans.svg" for key "Icon" in group "Desktop Entry" looks like a relative path, instead of being an absolute path to an icon or an icon name
Error on file "mega/netbeans/launcher/netbeans.desktop": Failed to validate the created desktop file

It appears that it doesn't like the rel path of the fallback icon?

3. the "Supported packagers" section of the readme would need adjusting i think and also list the new type.

[neilcsmith-net]

Thanks for looking @mbien The desktop file spec says icons must be absolute paths or the name to look up. Given that this script already handles desktop file installation into /usr/local/share or $HOME/.local/share it might be good to copy the png and svg icons to the correct places instead?

Given no review from Pieter still, cc'ing @geertjanw instead.

[oyarzun]

@neilcsmith-net @mbien Thanks for reviewing the PR. I've rebased the code and addressed @mbien comments:

1. Use realpath to resolve the absolute install path used in the desktop file (e.g. the icon path)
2. Update the readme with the new package type

[mbien]

works, thanks! There would be still the question of how to uninstall it again, but I think this should probably be fine as initial implementation.

[oyarzun]

works, thanks! There would be still the question of how to uninstall it again, but I think this should probably be fine as initial implementation.

I suppose the install script could create an uninstall script that deletes the directory and the desktop file.

[mbien]

right I had the same thought. What I also haven't tested is what happens when the folder is non-empty, the script will merge the content without warning I believe. Script should probably also fail when someone passes arguments to it, e.g "I am an interactive installer, no arguments expected.". But those things could be followups I suppose, no need to delay this PR even further.

[mbien]

features would also have the potential to build on top of each other. E.g if the folder is non empty it could check for the uninstaller and run it first. If there is none, it would refuse installing. That way it could upgrade in place.

[neilcsmith-net]

That way it could upgrade in place.

That's a point - all existing packagers are designed to allow upgrade in place.

no need to delay this PR even further.

I would like to see some input from FoAN people here before this is merged.