cant install vivaldi2 32bit due to libappindicator3-1:i386 on 64bit system
-
@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?
-
-