Package Details: ly 0.5.0-1

Git Clone URL: https://aur.archlinux.org/ly.git (read-only, click to copy)
Package Base: ly
Description: TUI display manager
Upstream URL: https://github.com/cylgom/ly
Licenses: custom:WTFPL
Conflicts: ly-git, python-ly-git
Submitter: cylgom
Maintainer: cylgom
Last Packager: cylgom
Votes: 13
Popularity: 3.43
First Submitted: 2018-09-23 19:46
Last Updated: 2020-02-03 16:36

Latest Comments

1 2 Next › Last »

Cristophero commented on 2020-04-25 07:39

Muchas gracias!

J5lx commented on 2020-04-21 11:25

Np, you’re welcome :)

ndowens04 commented on 2020-04-21 11:16

@J5lx ah ok thanks for the clarifying

J5lx commented on 2020-04-21 11:13

No, this is not the same. The way I did it, git will automatically use the correct version of each submodule according to the gitlink stored in the object database. If you use mv, it will instead use the HEAD of each submodule, which, in a package for a specific release, is highly undesirable because it means that the same PKGBUILD can potentially yield different build results depending on when it is built. Also, there’s always the chance that breaking changes get introduced in one of the submodules, in which case your solution would result in a build failure, but mine wouldn’t.

ndowens04 commented on 2020-04-21 01:54

To base on J5lx's PKGBUILD instead of using git submodule can also just do:

prepre(){

    cd "$srcdir/$pkgname"

for _i in argoat configator ctypes dragonfail termbox_next; do

    mv "$srcdir/$_i" sub/

done

}

J5lx commented on 2020-04-21 00:50

Oh, there’s one other thing I just forgot about: ly’s default PATH is actually not well-suited to Arch. It breaks Netbeans for example, see FS#60533. It would probably a good idea to adapt the configuration file accordingly in the PKGBUILD. Personally I’m currently using an empty default path in config.ini and leave the PATH entirely to /etc/profile.

J5lx commented on 2020-04-21 00:31

cygolm: I just cought up with the latest comments, maybe I can clarify some things. First of all, there’s no need for a merge, a rename or anything like that. After all, it is only a change to the packaging procedure, from a user perspective it shouldn’t make any difference. You can simply reupload the current version of this package as ly-bin (if you like) and switch this package over to building from source.

ly-git should continue to be a separate package. As per VCS package guidelines: “Suffix pkgname with -cvs, -svn, -hg, -darcs, -bzr, -git etc. unless the package fetches a specific release.” (emphasis is mine). This means that the difference between -git and non-git packages is that -git packages are generally built from git HEAD. In other words, git packages are based on the very latest, bleeding edge, potentially unstable development code, whereas non-git packages are generally built from the sources of the latest stable release. In particular, it’s perfectly fine for non-git packages to retrieve their sources via git as long as it’s a specific release.

Also, here’s an improved version of ndowens04’s PKGBUILD for Arch Linux: https://gist.github.com/J5lx/b9018cfa39128da2b9d9ea5c6a1f3d42 Compared to the original version, I’ve moved the submodules to sources (As per package guidelines) since it is generally considered bad practice to download stuff manually during the build. Also note how ly is cloned via git, but the exact version is specified via #tag=${pkgver}. I’ve also added backup to prevent pacman from silently overwriting configuration files and removed the executable bit from files that should not have it (see atmouse’s comment).

I realise this is a quite a bit to digest, so if you have any questions feel free to ask :)

Edit: wording + formatting

ndowens04 commented on 2020-04-19 07:25

Here is a way to do source version, just added it in Artix Linux

http://dpaste.com/1N8Y5WE

cylgom commented on 2020-02-28 18:52

@qubidt You're right, I didn't notice there was a sneaky AUR-specific version of the "Arch submission guidelines" page on the Wiki... They should me merged IMHO.

Anyway, I'm not sure how to handle this now. Won't requesting a package merge with a hypothetical ly-bin break everyone's setup? If my understanding is right, "ly-git" should also be renamed to "ly", so this is going to be a huge mess...

qubidt commented on 2020-02-19 19:10

@cylgom

J5lx has a point. This should be ly-bin