cant install vivaldi2 32bit due to libappindicator3-1:i386 on 64bit system
-
Mint is Debian derivative, why using Installing Linux snapshots on non-DEB/RPM distributions?
@lamarca That does not matter in the slightest. You have perhaps misunderstood the point of the script. It is to provide an install option when no other exists. 99% of the time that would be users on non-Deb/RPM systems. But the script works just fine on any Linux distro should you so desire.
-
@gwen-dragon Not going to work
-
@ruario said in cant install vivaldi2 32bit due to libappindicator3-1:i386 on 64bit system:
You have perhaps misunderstood the point of the script
I have. The way I understood there were two scripts one for DEB/RPM and the second for non-DEB/RPM. No compatibility (the 2nd script)
@ruario said in cant install vivaldi2 32bit due to libappindicator3-1:i386 on 64bit system:
But the script works just fine on any Linux distro should you so desire.
It's new for me, be sure I will try it.
-
I have. The way I understood there were two scripts one for DEB/RPM and the second for non-DEB/RPM. No compatibility (the 2nd script)
@lamarca No you have not because there is only one script
-
It's new for me, be sure I will try it.
@lamarca Don't. YOU do not need it. It is for people who cannot install with the official packages. You can… the script is not for you. All you will achieve is two installs, one from the script and one from dpkg/apt which will only lead to further confusion
-
@ruario said in cant install vivaldi2 32bit due to libappindicator3-1:i386 on 64bit system:
No you have not because there is only one script
Okay, I didn't check the second one.
@ruario said in cant install vivaldi2 32bit due to libappindicator3-1:i386 on 64bit system:
Don't. YOU do not need it. It is for people who cannot install with the official packages
I have been using rvp.sh for Snapshots and ..... apt-get install is for Stable only.
-
@ruario i really can open about double the tabs on 32bit browser than on 64bit[experience from 32 and 64 bit chromium]
-
@sid0 While I certainly would not accuse you of lying, I find that immensely hard to believe. Nonetheless if you want the 32bit, either use the install script:
sh install-vivaldi.sh -f -a i686
Or repackage the deb like so
mkdir /tmp/vivaldi-repack cd /tmp/vivaldi-repack wget https://downloads.vivaldi.com/stable/vivaldi-stable_2.0.1309.37-2_i386.deb ar p vivaldi-stable_2.0.1309.37-2_i386.deb control.tar.gz | tar xz sed -i 's/libappindicator3-1, //' control tar --warning=no-file-changed --no-recursion -czf control.tar.gz ./ ./postinst ./postrm ./control ./md5sums ./prerm ar r vivaldi-stable_2.0.1309.37-2_i386.deb control.tar.gz
Then install the repack
sudo apt install ./vivaldi-stable_2.0.1309.37-2_i386.deb
-
@ruario i'll try this, thanks
-
@ruario i was thinking, if the dependencies are taken from chromium browser project, the same problem should occur while installing 32bit chromium, but it didnt happen and i'm typing this on 32bit chromium! I downloaded 32bit .deb file from ubuntuupdates.org
why this is so? -
@sid0 Deb packages are nothing more than
ar
archives containing typically 3 files (4 for signed .debs). And you only really need care about two of the files. In the case of most packages (Vivaldi included), they are control.tar.gz (contains package meta-data) and data.tar.xz (contains all the files that make up package). Manipulating the former allows you to change properties related to installation, while changing anything in the latter alters the actual package. -
@sid0 those packages are maintained by Ubuntu personel.
They have no dependency for indicator libraries but (for example) requirechromium-codecs-ffmpeg-extra
, which is optional for Vivaldi packages.They also do not need to add additional maintainer signatures for package update (in a very 2009y way).
Or have a cronjob that duplicates this operation needlesly and fiddles with repository source setup. -
@sid0 I presume Ubuntu's package maintainers have removed it. I have no intention of doing the same. It'll just be an extra thing to maintain and likely regress, plus I still think this is a bad idea.
-
@ruario thanks a lot, repacking via command line worked. And i also did that manually by decompressing and repacking manually after editing the control text file, that was fantastic to learn something new! i didnt expect it to be that easy, plus it opened new doors for the future. Thanks again.
-
@sid0 Indeed it is a handy trick to know. I Frequently adjust packages for one reason or another. The current stable versions of Vivaldi for all architectures and package types were repackaged on my machine to work around a build issue we have. That is why they all have a release number of -2.
This actually gets recorded in the meta data of the rpms. Notice the "Build Host" line. I am a Slackware user and that is the host name of my machine
-
@becm Regarding your comment on a single user install being in a hidden directory. It made me think about if we could do things better. I subsequently realised that on many (most?) distros, the system provided (default)
~/.profile
sets up$HOME/bin
in the$PATH
if the directory exists.So I shall alter the script to drop symlinks for vivaldi and the uninstall script in
$HOME/bin
when this directory is present and inform the user of these, instead of echoing back locations under a hidden directory.This will also have the advantage that the user will be able to more easily start Vivaldi from a terminal, since they will not have to type the full path to the executable or uninstall scripts to run them.
P.S. I have already added this functionality to my test/development version of the Vivaldi, snapshot install script.
-
@ruario the
file-hierarchy(7)
man page favours~/.local/bin
as location for terminal compatible user executables.
Some pick it up (Fedora 28, Ubuntu 18.04) while others (openSUSE 15, Debian 9) seem to ignore their shipped(!) documentation…
The advantage would be to not (needlessly) clutter the home directory (additional precedingelif
?).Also according to this, I think the best match for Vivaldi package content might be
~/.local/lib/<arch-id>/<vivaldi-version>
.
But there may be little benefit in contrast to risks when of moving away from the variableXDG_DATA_HOME
… -
@becm The point was not to make place it in another folder that is equally hidden. Also the script does not (needlessly) clutter the home directory because it will not create the directory. It is only used if the user has already created it themselves. Granted
~/bin
is not any kind of designed standard but it is a defacto one and also has the advantage that more distros will look their out of the box, compared to~/.local/bin
.If
~/.local/bin
becomes more widespread in its support in the future, I could switch to that then.EDIT:
~/.local/bin
is actually a directory defined by systemd. As quite a few distros who are in the target audience of this script are wary of systemd, it kinda defeats the point by only adding it there, given it would primarily benefit those who are less likely to use the script. Better to continue with~/bin
but only if already present (i.e. do not created it).Also worth noting that snap packages (which we plan) also require systemd. So at the point we add snaps, the install script will be even more focussed on non-systemd distros.
-
I could switch to that then.
I merely wanted to suggest benefits to check for an additional location, making
~/.local/bin
an option if it exists (identical to conditions for~/bin
).
There should (now) only be little additional code required while usage patterns (for users) are identical.The alternate location allows users to keep their
$HOME
tidy (independent of the standard being defined by systemd).
The~/.local/bin
content is already expected to be available for and modified by other (user install) software.ModRequest, @ruario: would it be possible/desired/prudent moving the content since post 241376 to the script topic?
-
-