Package Details: i3blocks-contrib-git 2.0.0.r5.g7f601f8-1

Git Clone URL: https://aur.archlinux.org/i3blocks-contrib-git.git (read-only, click to copy)
Package Base: i3blocks-contrib-git
Description: Official repository of community contributed blocklets
Upstream URL: https://github.com/vivien/i3blocks-contrib
Licenses: GPL3
Groups: i3
Conflicts: i3blocks-contrib
Provides: i3blocks-contrib
Submitter: matoro
Maintainer: sshaikh
Last Packager: sshaikh
Votes: 3
Popularity: 0.000000
First Submitted: 2019-09-09 12:28 (UTC)
Last Updated: 2021-08-19 11:21 (UTC)

Dependencies (50)

Required by (0)

Sources (1)

Pinned Comments

sshaikh commented on 2021-08-16 11:28 (UTC) (edited on 2021-08-16 11:52 (UTC) by sshaikh)

@thiagowfx

The i3blocks-contrib repo contains the source code for various contributed to be used by i3blocks. As per upstream[1] they are not meant to be used "raw" by cloning but in fact are meant to be selectively built/copied into an existing script directory.

This allows upstream's default/example config to work correctly, as block names are by default taken from filenames in the script directory (ie it doesn't handle subfolders elegantly). So to answer your question directly, the difference between this package and i3blocks-contrib-git is that the latter simply clones and copies the repo (sub directories and all), while this one "flattens" it into an appropriate script directory.

There's more discussion in upstream's issue #255[2], including the inspiration for the code in this PKGBUILD.

@a821

I have raised this (as well as offering a solution) on i3blocks-contrib-git's AUR page[3], but received no meaningful response. As I was unable to determine if this was by design/preference or that the users of this package were actively expected to configure their systems in a way contrary to upstream, I didn't feel it was appropriate to adopt and correct it in a way that would break it for an existing audience. And so I uploaded an alternative package.

Hope that helps!

[1]https://github.com/vivien/i3blocks-contrib/wiki/Installation [2]https://github.com/vivien/i3blocks-contrib/issues/255 [3]https://aur.archlinux.org/packages/i3blocks-contrib-git/#comment-776755

Latest Comments

1 2 3 Next › Last »

thiagowfx commented on 2021-08-20 01:17 (UTC)

Thanks for your patience @sshaikh, happy to see this merged!

If you want to improve the PKGBUILD a bit more, here's a diff: http://ix.io/3wvc (TL;DR: use make -C instead of pushd and popd).

alerque commented on 2021-08-19 11:38 (UTC)

@sshaikh Just so you know, provides=("$_pkgname=$pkgver") should be fine without needing to strip off the extra segments. If the segments are constructed properly (it looks like yours are) then Arch'svercmp` will know how to compare them relative to stable tags so you don't need to strip it and pretend the Git is as old as/identical to the last tag.

sshaikh commented on 2021-08-19 11:30 (UTC) (edited on 2021-08-19 11:31 (UTC) by sshaikh)

Thank you for all the assistance with this. I've now updated the package to install the scripts in a more "appropriate" place. Further, I've integrated the changes recommended by @a821 which has actually resulted in a version bump to 2.x.

Existing users should expect their existing i3blocks config to break. Using the following in your config should get things working again: command=$SCRIPT_DIR/$BLOCK_NAME

alerque commented on 2021-08-19 09:30 (UTC)

Note about comment history: I've merged i3blocks-contrib-install-git into this package so many comments below came in from that package. @sshaikh You should adopt this and adapt your PKGBUILD with the path issues fixed and post it to this name.

sshaikh commented on 2021-08-16 13:58 (UTC)

Great. For clarity the problem was never with upstream but with the package. I take your point that it doesn't matter where a breaking change is if it's made to be "correct".

All moot now as I've submitted the orphan request. If I become maintainer I'll also make the changes you've describes further below.

Many thanks for the input!

a821 commented on 2021-08-16 13:49 (UTC)

@sshaikh With "upstream-changes" I meant, in general, changes made by the upstream developers that may break users' setups. Users should adapt to those changes.

In this particular case, I have no idea if it always was package wrongly, or there was a change made by upstream developers after the other package's original submittion (which is what you are trying to correct with this package). Either way, the package should be packaged correctly (as @alergue points out) and the users should fix their systems. If you adopt and fix the other package, informing the users with the required changes by for example a pinned comment will be great.

sshaikh commented on 2021-08-16 13:16 (UTC)

I've requested this package be orphaned as per https://aur.archlinux.org/packages/i3blocks-contrib-install-git/#comment-822105

sshaikh commented on 2021-08-16 13:14 (UTC)

@alerque

Sounds good, will do! If we can keep this around till then that would be appreciated. Once fixed I'll file the delete request myself if that's okay.

sshaikh commented on 2021-08-16 13:11 (UTC)

@a821

What do you mean by "upstream changes" here? Upstream hasn't changed, the potential error is in the way the package is being building it, ie in the AUR package ie it does not follow the install instructions provided by upstream.

The question is whether this should now be corrected, given how users have now adapted to been using the "broken" package. Doing it right now will break things for users who are perfectly happy.

Again, I don't have any objection in doing that, but neither do I necessarily want to be responsible for breaking systems the next time existing users update i3blocks-contrib-git, unless that's something that's been "signed off" by those in a position to do so.

alerque commented on 2021-08-16 13:09 (UTC)

This should be fixed in the other repository. The entire point of a package is a recipe to install something to your system. Cloning a repo and stuffing the files on a system is useless if that's not how they need to be used. Upstream may be just a dumping ground for scripts and not have an installer, but if there is going to be a package at all it needs to install things where they need to be to run.

Please file an orphan request on the other package and then set it up to be usable. Having a -install package for something that already exists as a package is never the right solution.

1 2 3 Next › Last »