Reintroduce install script #141
Comments
|
I have implemented INSTALL script as proposed. Users of "old stable" can now use this script to make installation easier and convenient. Tested usage: Tested result: The script is also copy-paste friendly, which is implemented by placing essential commands inside the gated hashes '###'. For details, refer to the raw text itself. P.S.: This issue will remain open for any feedback, while working on 4.1.4. |
|
While trying out latest code from There are two ways to solve this problem:
While no.1 is easy to do, that doesn't solve the leftover files that have been created by installation i.e. So no.2 does the job better. The clean up commands shall be added under The function might be renamed to just The INSTALL script will be revised later. |
|
I have revised INSTALL script with precaution. That is, leftover directories and files won't be removed unless user type Tested result (no leftover files) Tested result (with various leftover files) Tested result (with actual leftover files) There is one minor difference when running the script; In Debian,
Therefore, counting items for deletion is wasteful and considered a duplicate feature. Tested working in Xubuntu Trusty and Debian Xfce Jessie 32-bit host systems. |
REQUIRES coreutils and *not* debianutils); Renamed 'uninstall_bin' to 'uninstall', then added commands to clean up leftover directory and files with precaution.
Enhance #141 with renew script function and menu. Trivial clean up.
|
Following some code clean up for INSTALL script, I have added a new function today. Until now, user will have to type the following commands to download the INSTALL script. Do the same again and again, whenever INSTALL script is updated. Not anymore. From today onwards, user could do likewise above for just one last time. No more repeated typing to download INSTALL script. How is that possible? Read on. Tested result (with commit fb564c2) The new function adds menu called "Renew INSTALL script" with selection key When finished, the existing script has been renamed to Since the existing script has been renamed with prefix The only thing the function doesn't do is to execute the script again i.e. That is the only command user will need from today onwards. P.S.: I have actually designed another new function. The "Renew INSTALL script" action shall be immediately useful after adding that function later. P.S.S: Fixed grammar and word choice. |
|
I have pasted more output to demonstrate the behaviour of current INSTALL script. Tested result at first run (with commit earlier) Tested result when aborting (with commit earlier) Tested result when quit (with commit d2d337f) Additional notes While "Do nothing" message tells the obvious result to the user i.e. it does nothing and has been hinted earlier as The only other |
|
Today, I finally understood what was misleading in the INSTALL script. The action menu This means: There is nothing wrong in the implementation. The action basically does exactly what it says: Uninstall current version. Download source from master branch. Compile and install package [assuming newer version than existing]. Hence, latest version is installed. Meanwhile, README noted that "Customizer is stable and not under active development". This means: Even there is any commit being pushed to the repository, there will be no critical changes to how Customizer works, at least for "old stable" until future release 4.2.0. Therefore, latest version from "old stable" is somewhat odd and misleading by itself. May be it is just me. Then again, I could tell something is not right, perhaps with the word choice (common issue of user experience design in software development). Alternative word choices
Criterion For alternative choice, we ought to select either one that doesn't emphasize "latest". Why not "latest" Consider this analogy: Today, there is an article dated Dec 4, which is the "latest" news. The following day, Dec 5, when there is a newer article of the earlier news, the article dated Dec 4 is now considered as "yesterday's news" and it is not latest anymore. Because news often emphasize "latest" articles, the readers tend to check for updates every few hours or even every hour. Running updates "more often than each hour" is considered a waste of bandwidth, as noted by Liferea news reader.
Now translate the news analogy to software development, then what would happen? User will run the INSTALL script every hour to check/install the "latest" update in the repository, which is mostly waste of bandwidth and possibly abuse the convenience of the INSTALL script. Despite the possibility, this was never the intended way of using the script. In software development, words could guide the user to intended usage or otherwise mislead the user to unintended usage. Following above, proper wording is needed to prevent misleading use of the script. Verdict Based on above alternative word choices, I would opt for 5. With the new word choice, there is no feel of urgency to run the action and means better, isn't it? The changes shall be reflected soon in |
|
For the past few days, I have tested INSTALL script on various host systems. Tested result None of host system had shown any relevant errors, such as "package not found" or "dependencies not met", which is good. This also means First guide is still valid for newer release i.e. 16.04. One thing that worried me was the package availability or deprecation in newer release. For example, Perhaps the dependency should be renamed from P.S.: This is bit confusing... P.S.: Add note for Debian, which I had tested earlier also. |
ghost
mentioned this issue
|
While revising a new function, I felt something is not right again. The new word choice was intended to mean "no urgency to update" and yet, there is still something off with the word choice. The new word choice remained confusing in a sense. In particular, the word 'package' is ambiguous and confusing.
Following above, I have came up with a better word choice: That will be similarly adopted for the new function i.e. Proposed changes The following are changes that will be made at same time.
The expected result for first and second proposed changes is shown in the following output. The changes shall be reflected soon in P.S.: Tested INSTALL script and confirmed works as expected result. |
Better word choice for #141 and amend some text
ghost
mentioned this issue
|
The mentioned pull request brings many improvements to INSTALL script. Test results (as commit e0334d5) Test results for dpkg Few more improvements might be added later as part of milestone 4.1.5. Following this, I believe this issue can now be closed for good. |
Back in old days, there was an install script that handles installation of dependencies and source package. But that had been rendered obsolete since Customizer is now rewritten in Python.
Rationale
Now that readme has been simplified, I try to imagine how end users would install this tool.
Will end users refer to the linked manual or the wiki? No, most likely will refer to neither!
Typical end users might be too excited to work on remastering. This might suggest that, intuitively, they will just like "install this quick and start remastering!" and forget any further reading.
Also recently, I found a short walkthrough video on YouTube on "How to install ubuntu customizer" (No, we didn't upload that). Despite buried between much text in the old readme, the video had shown the command (sudo apt-get install... --no-install-recommends) was copied anyway. The following commands (make, sudo make install) were typed manually in the Terminal.
So what do above situations suggest? Three words: make installation easier
Why realize now
I have been not realizing this for the following reasons.
I had been accepting moderately tedious steps of DIY and RTM culture, since I had less convenience to install packages from outside Ubuntu repository, besides PPA back then.
I tend to be sceptical and do research first before using any stuff outside Ubuntu repository, although I found this tool on SourceForge, when it was quite trustworthy back then (research = I read enough information by the time I decide to install one).
I recently wrote my own script in Bash to make testing Customizer GUI easier i.e. running separate instances for different locale and authentication (pkexec, sudo); This reminds me back to the convenience of install script that was written by the original developer.
Proposed implementation
This initiative is to provide convenience, mainly end users, for installing Customizer in Ubuntu and Debian host system. The script shall fulfill the following requirements.
Include script in repo (This makes readily available while likely prevent from malicious modifications by monitoring GitHub commit history) at top level, name as
INSTALLwith all UPPERCASE letters and without file extension (This indicates flexibility, whether to allow opening this file in text editor for copy-paste or making script as executable);Write in Bash (This is relatively easier than Python to implement by me);
Keep it simple (No coloured or verbose output; No 'smart' checking for requirements; Just useful comments and commands to do the job; Prefer style that allows to easily copy-paste -- possibly separate essential commands at top and other built-in commands and script functions at bottom);
Include relevant steps (This will follow recommended instructions in 'First guide' on wiki, with enhancements for running the script; Hint started, one-time reminder and confirm user input to proceed, update or to quit/cancel installation, install package dependencies, download source from the repository, make deb and install via dpkg, hint finished)
Make documentation consistent (Remove command to install dependencies in
docs/manual.mdand replace with link toINSTALLfile instead; Update instruction no.3 in 'Installation' page on wiki)Edit: In step 5, include one-line text with link to allow discovery from the readme; Perhaps after the existing line "For quick reference..." can be included like "Else, skip reading and refer to INSTALL."
Expected result
When the script is made available, the installation would be as easy as:
So end users would download the script only, then the rest is handled by running the script.
Unlike old install script (I don't remember what was the behaviour of old script), the way I am going to implement will not require
sudoto run the script, although there will besudocommand inside to install dependencies and DEB package.The said approach may be inconvenient because if download and installation takes time, user may have to retype password to confirm installation of DEB package (I am unsure the exact behaviour). Then again, this shall be forgiven to ensure users' own safety when running any script.
The implementation may be subject to changes, if I notice any issues.
I hope to implement this by directly commit to
masterbranch, so that the script can be tested and enhanced on-the-go, prior to publishing patch release 4.1.4 later.The text was updated successfully, but these errors were encountered: