apt-get remove perl

Problem with different perl version, I did apt-get remove perl and apache2 sendmail mysql cpan got removed as well? Artificial intelligence?

Of cause I can re-install them andre

Reply to
ZOT
Loading thread data ...

It does ask if you want to proceed.

# apt remove perl Reading package lists... Done Building dependency tree Reading state information... Done [...] The following packages will be REMOVED: apache2 apache2-bin apache2-suexec-pristine autoconf automake [...] 0 upgraded, 0 newly installed, 173 to remove and 0 not upgraded. After this operation, 558 MB disk space will be freed. Do you want to continue? [Y/n] n Abort. #

Dependency management. If you remove something that apache2 depends on, it will remove apache2 as well.

--
https://www.greenend.org.uk/rjk/
Reply to
Richard Kettlewell

You can?t do that without breaking the system.

I?m not sure what the question is. You can use Perl for whatever purpose you like.

--
https://www.greenend.org.uk/rjk/
Reply to
Richard Kettlewell

OK but then how is sendmail, mysql and apache depending on perl? BTW I still have a version of perl installed?? I suppose the extra perl came when installing one the above. Of cause, I will re-install apche mysql sendmail as I think to use them. I am just a little bit bored with this kind of functioning.

Reply to
ZOT

I don?t know what the functional dependency is. If you really want to know then you can inspect their contents.

--
https://www.greenend.org.uk/rjk/
Reply to
Richard Kettlewell

apache, sendmail and mysql are systems services they should not depend on a language and certainly not on perl. ( why not basic??) If they depend on some library tight to perl, those library should not be removed but not the system service. BTW apt-get removed perl, mysql.. but re-installed php 7.3??

Reply to
ZOT

That is only true if they are written in a language that compiles to native binary code for the computer that its running on AND any libraries it depends on are statically linked into the binary.

Packages with dependencies on any other packages will be broken if you remove the packages they depend on, so the convention is that the package manager (apt for Debian/Raspbian, dnf for Fedora/RHEL) will ask for confirmation if you try to remove a package that other installed packages depend on and lists them so you can understand the consequences.

If you choose to go ahead and delete the package, then you have voluntarily accepted that all the dependent packages will also be removed.

Of course it should do that: you may have decided that you are repurposing the computer as, say, a file store or a firewall and you've decided that, as it will no longer be used to execute Perl, Java or Python programs, you'll remove all of these for security reasons.

Simple: php is dependent on the pcre library, not Perl, and the pcre library is not written in Perl and so is also not dependent on any Perl packages, so was not affected by your removal of Perl from your RPi.

--
Martin    | martin at 
Gregorie  | gregorie dot org
Reply to
Martin Gregorie

On Thu, 26 Sep 2019 11:45:44 +0200, ZOT declaimed the following:

But is it the /OS/ version of PERL -- or one that was installed into an alternate location that the system does not reference.

What does which perl display? Mine shows /usr/bin/perl.

On a recent Beaglebone I installed the vim-gtk3 package... That's a package that provides the vim editor along with gvim (graphical interface) version...

It sucked in half a doze /ruby/ related packages!

debian@beaglebone:~$ sudo apt-install vim-gtk3get Reading package lists... Done Building dependency tree Reading state information... Done

The following additional packages will be installed: fonts-lato liblua5.2-0 libruby2.3 libyaml-0-2 rake ruby ruby-did-you-mean ruby-minitest ruby-net-telnet ruby-power-assert ruby-test-unit ruby2.3 rubygems-integration vim-gui-common zip

And if they require certain packages, like PERL, then that PERL will be reinstalled with them.

For normal package manager installs, there will only be ONE version of anything. They normally don't install multiple versions (well, Python typically has a 2.x and 3.x version -- with the OS normally using just one of them, and users have to specify the other

pi@raspberrypi:~$ which python /usr/bin/python pi@raspberrypi:~$ which python3 /usr/bin/python3 pi@raspberrypi:~$ python Python 2.7.16 (default, Apr 6 2019, 01:42:57) [GCC 8.2.0] on linux2 Type "help", "copyright", "credits" or "license" for more information.

pi@raspberrypi:~$ python3 Python 3.7.3 (default, Apr 3 2019, 05:39:12) [GCC 8.2.0] on linux Type "help", "copyright", "credits" or "license" for more information.

pi@raspberrypi:~$

pi@raspberrypi:~$ ls -l /usr/bin/python* lrwxrwxrwx 1 root root 7 Mar 4 2019 /usr/bin/python -> python2 lrwxrwxrwx 1 root root 9 Mar 4 2019 /usr/bin/python2 -> python2.7

-rwxr-xr-x 1 root root 2984816 Apr 5 21:42 /usr/bin/python2.7

Note how "python" is a link to "python2" and that itself is a link to "python2.7".

pi@raspberrypi:~$ ls -l /usr/bin/perl*

-rwxr-xr-x 2 root root 2844532 Mar 31 07:51 /usr/bin/perl

-rwxr-xr-x 2 root root 2844532 Mar 31 07:51 /usr/bin/perl5.28.1

-rwxr-xr-x 1 root root 5632 Mar 31 07:51 /usr/bin/perl5.28-arm-linux-gnueabihf

Interestingly, they didn't link perl to perl5.28.1even though they are identical.

pi@raspberrypi:~$ sudo apt-cache showpkg apache2 Package: apache2 Versions:

2.4.38-3 (/var/lib/apt/lists/raspbian.raspberrypi.org_raspbian_dists_buster_main_binary-armhf_Packages) Description Language: File: /var/lib/apt/lists/raspbian.raspberrypi.org_raspbian_dists_buster_main_binary-armhf_Packages MD5: d02426bc360345e5acd45367716dc35c

Reverse Depends: umegaya,apache2 2.4.9~ ajaxterm,apache2 Dependencies:

2.4.38-3 - dpkg (2 1.17.14) apache2-bin (5 2.4.38-3) apache2-data (5 2.4.38-3) apache2-utils (5 2.4.38-3) lsb-base (0 (null)) mime-support (0

(null)) perl:any (0 (null)) procps (0 (null)) apache2.2-bin (0 (null)) ^^^^^^^^^^^^^^

apache2.2-common (0 (null)) libapache2-mod-proxy-uwsgi (3 2.4.33) ssl-cert (0 (null)) apache2-doc (0 (null)) apache2-suexec-pristine (16 (null)) apache2-suexec-custom (0 (null)) www-browser (0 (null)) apache2.2-bin (0 (null)) apache2.2-common (0 (null)) libapache2-mod-proxy-uwsgi (3 2.4.33) Provides:

2.4.38-3 - httpd-cgi (= ) httpd (= ) Reverse Provides: pi@raspberrypi:~$

Apache2 requires some version of PERL to be in the system path.

--
	Wulfraed                 Dennis Lee Bieber         AF6VN 
	wlfraed@ix.netcom.com    http://wlfraed.microdiversity.freeddns.org/
Reply to
Dennis Lee Bieber

No they are applications.

Apache is probably built with mod_perl which requires perl, mysql probably with perl bindings or possibly with perl based utilities. Sendmail is the only one that surprises me, but probably some of the newer integrations.

Apache is probably built with PHP support too.

--
Steve O'Hara-Smith                          |   Directable Mirror Arrays 
C:\>WIN                                     | A better way to focus the sun 
The computer obeys and wins.                |    licences available see 
You lose and Bill collects.                 |    http://www.sohara.org/
Reply to
Ahem A Rivet's Shot

how to start|stop apache, mysql, sendmail

service apache2 start.

I plan to do as I did long ago : build myself mysql, apache and sendmail. To have smrsh with sendmail I already downloaded sendmail sources. With my raspberry first edition, it will take a looong while but I have plenty of time since I am retired.

Reply to
ZOT

Which Raspbian version are you using?

Buster is the current one, replacing Stretch. For both, the command is

sudo systemctl start|stop|status application

Before that (wheezy, jessie) you'd use the older system v commands to control daemons.

--
Martin    | martin at 
Gregorie  | gregorie dot org
Reply to
Martin Gregorie

service xx start|stop|.. is a substitude of systemctl.. I do not need sudo as I modified sudoers to disallow sudo.

Reply to
ZOT

Don't remove any of the popular scripting languages from Linux, many other packages depend on them, and you will end up removing a lot of important functionality. The scripting languages themselves don't take up much room, and there are many bigger packages provided with Raspbian that hardly anyone uses, which can be removed to free up space (e.g. Wolfram). Alternative just make up a card from the Raspbian lite image.

---druck

Reply to
druck

If space is limited far better to boot a minimal install and then add what you need and accept that e.g. apache will pull in PHP and PERL most likely

--
?Some people like to travel by train because it combines the slowness of  
a car with the cramped public exposure of ?an airplane.? 

Dennis Miller
Reply to
The Natural Philosopher

On Sat, 28 Sep 2019 16:09:03 +0100, The Natural Philosopher declaimed the following:

Or move up to a higher capacity uSD card. After all this is not a case of trying to fit everything into a BBB 4GB eMMC [I tend to run those off an

8GB uSD, when using the "IoT" OS -- don't need the LXQT graphical environment; R-Pi 3B(+) tend to get a 16GB card as it is more difficult to reduce the NOOBS/Raspbian-full).
--
	Wulfraed                 Dennis Lee Bieber         AF6VN 
	wlfraed@ix.netcom.com    http://wlfraed.microdiversity.freeddns.org/
Reply to
Dennis Lee Bieber

$ df -h Filesystem Size Used Avail Use% Mounted on /dev/root 15G 1.7G 13G 13% / devtmpfs 213M 0 213M 0% /dev tmpfs 217M 0 217M 0% /dev/shm tmpfs 217M 22M 195M 11% /run tmpfs 5.0M 4.0K 5.0M 1% /run/lock tmpfs 217M 0 217M 0% /sys/fs/cgroup tmpfs 1.0M 8.0K 1016K 1% /var/MiPiFi /dev/mmcblk0p1 44M 23M 21M 52% /boot

Thats a pi-zero running apache with PHP.. and no gui

Rapsbian Lite Easy to fit on 2GB

--
?It is dangerous to be right in matters on which the established  
authorities are wrong.? 

? Voltaire, The Age of Louis XIV
Reply to
The Natural Philosopher

Plus the smaller and fuller the SD card, the sooner it will die. You should aim use less than 50% of the card, so there is plenty of room for wear levelling.

---druck

Reply to
druck

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.