search

projecthamster / hamster-shell-extension

Shell extension for hamster
http://projecthamster.org
GNU General Public License v3.0
215 stars 91 forks source link

Set TAR archive root directory or update installation instructions #290

Closed redcatbear closed 4 years ago

redcatbear commented 6 years ago

Situation

When installing the extension manually from the Git development branch, one of the last steps is to unpack the TAR archive in the local extensions directory.

According to the documentation the archive should be unpacked in the root of the extensions directory. Given the current tar layout, this unpacks the contents directly there instead of under a sub-directory contact@projecthamster.org

Possible solutions

a) Make contact@projecthamster.org the root directory of the TAR archive.

Documentation can then be unchanged. Most convenient for end user.

b) Update documentation

cd ~/git
git clone https://github.com/projecthamster/hamster-shell-extension.git
git checkout develop
make dist
cd ~/.local/share/gnome-shell/extensions/
mkdir contact@projecthamster.org
cd contact@projecthamster.org
tar xzf ~/git/hamster-shell-extension/dist/contact@projecthamster.org.tgz
DirkHoffmann commented 4 years ago

Thank you for your feedback, @redcatbear, and sorry for the delay in picking this up. There are several ways to fix it. As far as I can see, 17d2bc7 addressed it successfully as well.

It was merged into the develop branch, but not master. @benjaoming, as you are the legitimate author, would you mind to create the PR (and that I assign this issue to you)?

hedayat commented 4 years ago

Well, it is too late to say my opinion, but I wonder why the first solution was not preferred? It was always a mystery for me why the extension is packaged like that. I think it was much better if it was already packaged inside the required directory.

DirkHoffmann commented 4 years ago

It's not too late. The main constraint that I see is that the ZIP archive needs a "rootless" structure, which does not contain the extension UUID. That's GNOME's choice, and we cannot change it. Then, we have the TAR file. (I actually wonder why, besides the fact that it's "more unix-like".) We could have a different structure (with UUID as root directory) in the TAR file than in the ZIP file. But then it would be confusing for users (and occasional developers), as we would have different ways to install from TAR or from ZIP (and approriate instructions).

@benjaoming, you did not object to be the assignee. What is your opinion?

mwilck commented 4 years ago

@hedayat, I agree, but please let's not change this before the GNOME 3.3x support PRs have been merged. Fixing this is trivial, but if it's done and merged now, I'll have to rebase all 3 PRs #312, #316, and #323. I already did for #310.

hedayat commented 4 years ago

@mwilck Yeah, I'm not in hurry :)

@DirkHoffmann Oh, I didn't know about the ZIP structure. If so, well, I'm not sure. ZIP is OK probably because it is designed to be used automatically. But for manual installation (tar?) I'd prefer having the UUID part too.

benjaoming commented 4 years ago

@benjaoming, you did not object to be the assignee. What is your opinion?

This was fixed in https://github.com/projecthamster/hamster-shell-extension/pull/310 ?

DirkHoffmann commented 4 years ago

My 2 cents on this:

  1. Instructions have been updated (i.e. corrected) in #310. :+1:
  2. The TAR may contain the path, the ZIP must not. If we add the UUID directory to the path, this breaks compatibility and #310 has to be reverted. In the transition, we might have two different methods/instructions, depending on the branches / shell versions. :-1:
  3. TAR and ZIP are redundant technologies for the same problem: bundling files. This is confusing, and one of them should be removed. :question: 3.1 If a "more *nix-like" solution is needed for the test/dev installation, a simple cp -r might make do, or a combination of pipied tar and eventually mkdir. No need to create the TAR file explicitely. 3.2 It would be more difficult to change the UUID name in tests, if it were generated inside the TAR file.

In my opinion a cleverly coded target for mak e test or make test-install might be sufficient and a good complement. What do you think about this, @mwilck, @hedayat, @redcatbear? If you are not totally opposed to the idea, I make a more concrete proposal as PR for discussion. Otherwise I think this issue itself can be closed with solution #310 (by option b) in the OP).

mwilck commented 4 years ago

I like the idea of having the UUID in the tar, and adhering to the GNOME standard in the zip. Yes, generating both tar and zip is redundant, but does it hurt anyone?

DirkHoffmann commented 4 years ago

Does not hurt, but confuses. But with the path included, they have two different purposes. No strong objection from my side.

If anybody feels that it is an error to close this, please reopen.

matthijskooijman commented 4 years ago

One additional datapoint: A reason to have a top-level directory in a tar file, is that it is conventional to do so. Software released in tarballs almost always do this, so I'm coming to expect that I can unpack a tarball without having to create a directory first.

For zips, I think think the convention is more often to not have a top-level directory.

One other angle would be to report a feature request to the GNOME folks to accept zips with a top-level directory as well (should be possible in addition to the current zips).

hedayat commented 4 years ago

First, note that there is also #330 and it will change installation instructions anyway.

I'm not opposed to keeping tar output, but I myself wouldn't care much about it if a proper install target exists for make. Also, the zip file might be somehow designated that it is not suitable for manual usage, and it is only provided to be used by gnome shell tools/distribution. Or, it should not be generated at all during the manual installation instructions. Which is satisfied by a solution like #330 already.

DirkHoffmann commented 4 years ago

Thank you, @hedayat. Let's follow up on #330 then.