search

vivien / i3blocks-contrib

Official repository for community contributed blocklets
https://github.com/vivien/i3blocks
Other
1.31k stars 486 forks source link

Consider renaming blocklets which conflict with non-contrib scripts #78

Open roobre opened 7 years ago

roobre commented 7 years ago

Hello,

I'm considering to write a PKGBUILD for this repo, to allow easy deployment and updating of contrib blocklets.

I think the better approach is to install these scripts to the same path where the non-contib scripts are located (/usr/lib/i3blocks on archlinux), as not using additional command= lines makes the i3blocks.conf cleaner. However, as some of the contrib scripts share names with the original ones, most package managers (pacman included) complains about conflicting files.

Can we consider renaming those blocklets whose name conflicts with the default i3blocks scripts? (bandwidth, battery)

kb100 commented 7 years ago

I would consider renaming blocklets to prevent overlap just to avoid confusion, but I don't know if /usr/lib/i3blocks is the right place for contrib blocklets. Doesn't it make more sense to put them in an i3blocks-contrib specific directory? Although I do coordinate with vivien, the repos are quite independent and either one of us could easily step on the other's toes on accident if the scripts were kept in the same place. Perhaps one could store them in /usr/lib/i3blocks-contrib and put a link to blocklet as blocket-contrib in /usr/local/i3blocks? That way in your config all your contrib blocks are clearly marked. I've never dealt with packaging before so please excuse any terrible suggestions.

roobre commented 7 years ago

I don't know if /usr/lib/i3blocks is the right place for contrib blocklets

This actually depends on each distro's packaging guidelines From the arch wiki:

Avoid using /usr/libexec/ for anything. Use /usr/lib/$pkgname/ instead.

As i3blocks-contrib is essentially an addon for i3blocks, I think putting the contents on the same place is a good idea (it also simplifies the config file, as I already said). Other packages which act as modules for "core" ones also follow this convention. It comes to my mind php, which owns /usr/lib/php/modules, and php-gd, which places its own .so file into that directory.

But of course, this might apply to arch only.

Perhaps one could store them in /usr/lib/i3blocks-contrib and put a link to blocklet as blocket-contrib in /usr/local/i3blocks?

This could be a feasible solution, but it would add complexity to the package. It technically is an it-just-works solution, but not the most optimal one, at least in my opinion.

Also, despite of the package management perspective, I think having contributed and default blocklets with the same name but different behaviour can lead to confusion. I'd recommend avoiding this scenario.