-
Notifications
You must be signed in to change notification settings - Fork 92
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Set TAR archive root directory or update installation instructions #290
Comments
Thank you for your feedback, @redcatbear, and sorry for the delay in picking this up. 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)? |
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. |
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. @benjaoming, you did not object to be the assignee. What is your opinion? |
@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. |
This was fixed in #310 ? |
My 2 cents on this:
In my opinion a cleverly coded target for |
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? |
Does not hurt, but confuses. If anybody feels that it is an error to close this, please reopen. |
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). |
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. |
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
[email protected]
Possible solutions
a) Make
[email protected]
the root directory of the TAR archive.Documentation can then be unchanged. Most convenient for end user.
b) Update documentation
The text was updated successfully, but these errors were encountered: