purge will also remove any config files and other remnants where as remove just removes the package, well in fact it doesn’t even remove it as such, you need to run “clean” to delete the package and get your disk space back.
[email protected]:~ $ sudo apt-get remove php-redis
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following package was automatically installed and is no longer required:
php-igbinary
Use 'sudo apt autoremove' to remove it.
The following packages will be REMOVED:
php-redis
0 upgraded, 0 newly installed, 1 to remove and 0 not upgraded.
After this operation, 401 kB disk space will be freed.
Do you want to continue? [Y/n] y
(Reading database ... 105371 files and directories currently installed.)
Removing php-redis (3.1.1-1) ...
[email protected]:~ $ sudo apt autoremove
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages will be REMOVED:
php-igbinary
0 upgraded, 0 newly installed, 1 to remove and 0 not upgraded.
After this operation, 86.0 kB disk space will be freed.
Do you want to continue? [Y/n] y
(Reading database ... 105367 files and directories currently installed.)
Removing php-igbinary (2.0.1-1) ...
[email protected]:~ $
remove - just removes the package from the os not from the disk
purge - removes the package and associated files like personal settings etc
auto-remove - removes any packages that are no longer required as a result of removing packages that had previously caused other dependencies to be installed.
clean - actually removes all of the above from disk, think emptying a recycle bin in windows.
If I recall correctly, clean only removes the .deb packages stored in the local cache.
remove - removes the installed package, but not the cached package.
purge removes the installed package and configuratin files, but not the cached package.
purge can also be used with autoremove to delete the associated config files.
From the apt-get manpage:
clean clears out the local repository of retrieved package files. It removes everything but the lock file from /var/cache/apt/archives/ and /var/cache/apt/archives/partial/
This is where the disk space is reclaimed. Every time apt-get install runs, the .deb packages get cached.
Over time, the local cache can grow quite large. Running apt-get clean deletes all the cached packages.
My suggestion is that this dependency should be broken out as a separate item with a note, as installing it may disturb a previously setup solution for time syncronisation. I’m also not sure if Rasbian Stretch includes any time sync by default.
I’m not convinced it’s an emoncms dependency, yes emoncms needs to know the correct time and possibly the TZ, but it get’s that from the OS, If the OS is dependent on NTP that’s a different matter and needs addressing elsewhere IMO. However, if the OS has fully functional time and date then why are we installing NTP on top?
Stretch no longer uses ntp or ntpd, the timekeeping is done via timedatectl
[email protected]:~ $ timedatectl status
Local time: Mon 2018-02-19 00:54:43 UTC
Universal time: Mon 2018-02-19 00:54:43 UTC
RTC time: n/a
Time zone: Etc/UTC (UTC, +0000)
Network time on: yes
NTP synchronized: yes
RTC in local TZ: no
Personally I have never included ntp on my emoncms dependencies list and I’m unaware of any consequence of that, having said that it was included with wheezy and Jessie distros, but it is not in Stretch.
I too would have concerns about having 2 time syncing system active on one device, it is possible to disable the timedatectl service and install ntp, but I do not know if the ntp installer would be clever enough to disable the timedatectl or if indeed it is essential to do so, but I don’t see this as a emoncms concern as it’s an OS issue.
Which in itself maybe a problem with the RO filesystem as discussed in the linked thread.
I don’t know that it would, but equally as the move is to timedatectl, the method to synchronise time should be left to the user rather than be foisted on them with no real explanation or warning.
TBH, that’s why I left NTP in the build guide, to ensure that if timedatectl couldn’t write to /var/lib/systemd/timesync/clock because of the read-only OS, then at least NTP would manage timekeeping.
But if it’s not needed, I’m happy to remove.
I haven’t updated my RO images to Stretch yet, but timekeeping and handling the RO status have nothing to do with emoncms, that’s the OS. Even “ntp” will not work on RO OS’s without installing the “ntp-backup” mod. Any changes made to overcome the RO changes should be part of those RO changes, otherwise those changes are incomplete.
Just adding “ntp” to the dependencies will not make the fake-hwclock file writable, nor will it include Glyns more recent hack to reset the time after boot as that too is a separate bespoke mod, AFAICT adding ntp to the dependencies here in the emoncms install guide has no purpose, unless emoncms is dependent on it regardless of whether it’s an RO OS or not.
Questioning the necessity of the packages is a good thing, we should only be installing what is necessary to this part of the install, as a rule rather than justifying why it should be removed, we should be removing everything we cannot justify keeping in.
Perhaps we should even include a little table or list of dependencies and why they are needed and what they do as part of the guide, that would help with questions like these and a couple of years down the line we will all know why we included certain packages. Take the dio PECL package as an example, if it was documented that we were installing that to support accessing the serial port direct from emoncms, it may have been dropped in any one of the many documentation revisions there has been over the years.
From another recent discussion about installling emoncms
I get the impression he was rather stressed by the issue he was battling when he wrote that comment, but tone aside, its a fairly valid point.
Yes, sorry about that. It’s just quite annoying having to figure out dependencies from a list of packages for a specific Linux distribution and then ending up with something that doesn’t work as intended - the process of then figuring out if it is a missing dependency or actually a bug is rather annoying and IMHO unnecessary.
Apart from NTP I think the “ufw” package is also unnecessary as it is completely unrelated to the emoncms installation/functionality and is just confusing if one tries to figure out the general dependencies for installation on other OSes.
It’s probably worth pointing out that I didn’t write or maintain the Linux docs, as I don’t have a Linux installation to test.
I just wrote the messy sudo-code-dump.
To be fair - those code-dumps are better than nothing at all (e.g. just a install-script and no documentation at all) and at least you put them in the docs.
It might be that I’m more old-fashioned about becoming root to get the job done and drop privileges afterwards instead of wasting my time typing sudo a couple hundred times a day. So if I see instructions that begin with sudo on each and every line, my eyes begin to bleed
No problem! We’ve all been there and it is frustrating, we’re glad you voiced an opinion.
Jury’s still out on this in my mind, I totally get what you say, not disputing any points made. But there is no better place for it than when installing the LAMP, it could be an optional step, but IMO it should not be moved elsewhere or omited from the emoncms install guide (or more accurately the LAMP install guide) that is a prerequisite for the actual emoncms install.
With a proper list of dependencies and why they are there, users can chose not to install ufw by omitting it from their own cut and paste, but we must cater for the masses which will be raspbarrypi/emonbase/emonPi users.
Similar situation apllies to redis, we recommend it, therefore it is in the command string, but not all users can or will install redis, it isn’t actually a mandatory “dependency” as such.
But we can all have differing opinions, finding the better solution for the broader audience is the key.
And to be fair to you Paul, a lot of it was carried over from the previous guides, they’ve needed some attention for a while now. So any comments I’ve made are not directed at you, I know they are an accumulation of efforts.
That’s ok if you are fully aware of what your doing. When novice users are stepping through the guide copying and pasting the commands it is better to keep sudo in so novices can use, more advanced users like yourself can just copy from after the “sudo”. Although I do run my install scripts as root and manage the ownership and permisions explicitly as it goes, I don’t think that’s a viable approach for the guide, so I think all the sudo’s are most likely here to stay in the guide I’m afraid.
I’ve always based OS updates on the previous version, because it’s a ‘reliable’ starting point, and just made edits where there is a change (such as Mariadb etc.).
Definitely not taken your comments personally, you are much more knowledgeable than I am in writing code & understanding the intricacies of the OS.
I do welcome a shared input into developing the build docs, and @borpin and yourself have made a considerable contribution.
