Package Details: 2048.c-git 20150412.c9bba68-1

Git Clone URL: https://aur.archlinux.org/2048.c-git.git (read-only)
Package Base: 2048.c-git
Description: Console version of the game "2048" for GNU/Linux
Upstream URL: https://github.com/mevdschee/2048.c
Licenses: custom:MIT
Conflicts: 2048.c
Provides: 2048.c
Submitter: sekret
Maintainer: vesath
Last Packager: vesath
Votes: 8
Popularity: 0.008734
First Submitted: 2014-04-05 12:03
Last Updated: 2015-06-08 20:47

Dependencies (1)

Required by (0)

Sources (1)

Latest Comments

vesath commented on 2014-05-17 08:31

Added armv6h and armv7h without pkgrel bump.

Yamakaky commented on 2014-05-17 08:06

It compiles on armv6h (raspberry pi).

vesath commented on 2014-05-17 04:29

Thanks sekret for your hard work. I've adopted this package, made a few minor changes to have it match my packaging standards, and you can trust me to be oblivious to non-constructive comments.

sekret commented on 2014-05-13 16:23

No!

Of course I see your point, but it doesn't make sense to me. This is a git package, there are no releases. All I can do is update the PKGBUILD in case something needs to be changed so it can still be built, or if new infos come in like the successful build on the raspberry, thanks for that! Then of course the pkgver will be up to date, which it will be in a few seconds.

But what you are suggesting is just like updating with every new commit. Or should I do it every 10 commits? Or every week, month? What's the rule here? It's stupid in my opinion.

About yaourt, it at least used to (and probably still does) have an option to update all git, svn etc packages in a row. Just do this like once a week or month or something and be happy with it.
But do this only if you don't download the whole git tree every time! Configure makepkg to use at least one source directory for every package (SRCDEST in /etc/makepkg.conf), but look at all choices of the PACKAGE OUTPUT section of the makepkg.conf.

Of course with a small project like this one here the unneccessary traffic to download the whole tree is very small so it doesn't make a big difference, but still, that's not how one uses git!

Even better would be to actively follow the development of the projects you use the git version of. Why use the git version in the first place and not stick to stable releases? This only really makes sense if you follow its development!

The only point in time when I'll upload a new PKGBUILD only with an updated pkgver would be, if there actually is a snapshot, which got tagged as a stable version, so the version here represents a stable release. I will think about that, but I'm not sure if I'll do this. Probably not, because I consider git packages to be in a constant stream of updates / snapshots of the current state of the project, just like there's no real version of Archlinux, only snapshots.

Maybe this should be discussed officially, like on the aur-general mailing list. I might be wrong, sure, but I really thought about this a lot and to be honest, it's totally going on my nerves if maintainers of git packages update their PKGBUILD all the time even if the changes done in the past commit are so absolutely boring and really not worth a single thought (like updating some OSX or Win related code on multi-platform projects). Why then should I rebuild the whole thing, if the only thing that changes for me is the pkgver?! Consumption of unneccessary power, that's what this is, nothing more.

Yamakaky commented on 2014-05-13 15:46

You don't have to update pkgver at each commit (`pkgver()` is there for that), but if you don't do it sometimes, users can get stick to a version. Example :

- pkgver = 52
- upstream = 60

The user install the package, pkgver is updated to 60. Now, update on upstream :

- pkgver = 52
- upstream = 72
- installed = 60

This user has to manually re-install the package to get the last version. If you update pkgver to 72, he only has to run `yaourt -Syua`.

Convinced ?


The package compiles on armv6h arch (Raspberry Pi).

sekret commented on 2014-05-12 19:51

Why the fuck is this package flagged out of date?? It still builds, it still works.
It's a git package!! I won't upload a new PKGBUILD every time there's an update on github! No thanks, not my intention and doesn't make any sense.