Clyde - A better libalpm/makepkg wrapper

EnvoyRising · 2010-04-04 17:26:55

Dieter@be wrote:

JohannesSM64 wrote:
Dieter@be wrote:
- wouldn't it be easier to read pacman.conf and only put clyde-specific things in clyde.conf?
Clyde is a pacman replacement, not a wrapper. It does not make sense to read pacman.conf.
Uhm yes it does. exactly because it's design goal is to "be an easy move from pacman". I suggest you take a look at clyde.conf; 90% of it == pacman.conf

-1

Uhm no it doesn't.

Being that it's a pacman "replacement", as soon as pacman is uninstalled, pacman.conf is removed. As such, if only clyde-specific things are in clyde.conf it clyde itself would no longer work.

As for the design goal, you quoted the operative word: "from", suggesting that you will no longer need pacman. Or perhaps I'm just reading too much into the semantics...

pogeymanz · 2010-04-04 17:38:12

Dieter@be wrote:

JohannesSM64 wrote:
Dieter@be wrote:
- wouldn't it be easier to read pacman.conf and only put clyde-specific things in clyde.conf?
Clyde is a pacman replacement, not a wrapper. It does not make sense to read pacman.conf.
Uhm yes it does. exactly because it's design goal is to "be an easy move from pacman". I suggest you take a look at clyde.conf; 90% of it == pacman.conf

Sure, but if it is supposed to replace pacman, it means you can install clyde without pacman on your system. Or at least install clyde and then remove pacman. So pacman.conf may not exist and it would be silly to parse something that doesn't exist.

gazj · 2010-04-04 17:54:30

Hi, don't know if this has already been reported, but when doing a -Syu --aur, the aur packages freeze at then end of installation the only way out is C-c, -U did this at one point, I guess they would be related. They do install tho because on the next -Syu --aur they are no longer shown as an upgrade

Not every package seems to fo it, libmobiledevice usbmuxd did it, but ifuse did not. This was the last package to be upgraded. Maybe it's only when there is another aur packge to follow. Just throwing in some ideas

Thanks for Clyde it is ace

Last edited by gazj (2010-04-04 17:58:51)

LeoSolaris · 2010-04-04 19:41:38

Two things...

Tried uninstalling pacman just to see if it would actually work, and the removal took out libalpm, which killed clyde. The replacement involved reinstalling pacman from source and having to quickly swap between terminals to install pacman through clyde while the libs were still in ram as I used the uninstall script in the source folder to remove the source installed version of pacman. At least that is what I am pretty sure I did.

I tried it again, and it gives this error message:

lua: error loading module 'lualpm' from file '/usr/lib/lua/5.1/lualpm.so':
    libalpm.so.4: cannot open shared object file: No such file or directory
stack traceback:
    [C]: ?
    [C]: in function 'require'
    /usr/share/lua/5.1/clydelib/util.lua:2: in main chunk
    [C]: in function 'require'
    /usr/bin/clyde:5: in main chunk
    [C]: ?

Second curiosity... is it possible to replicate powerpill/aria's segmented, multi-threaded download capacity?

Last edited by LeoSolaris (2010-04-04 20:14:50)

pogeymanz · 2010-04-06 00:26:28

Where does clyde build packages from AUR? /tmp?
Will there be any way to make clyde build them elsewhere?

flamelab · 2010-04-06 00:38:20

LeoSolaris wrote:

Two things...
Tried uninstalling pacman just to see if it would actually work, and the removal took out libalpm, which killed clyde. The replacement involved reinstalling pacman from source and having to quickly swap between terminals to install pacman through clyde while the libs were still in ram as I used the uninstall script in the source folder to remove the source installed version of pacman. At least that is what I am pretty sure I did.
I tried it again, and it gives this error message:
lua: error loading module 'lualpm' from file '/usr/lib/lua/5.1/lualpm.so':
    libalpm.so.4: cannot open shared object file: No such file or directory
stack traceback:
    [C]: ?
    [C]: in function 'require'
    /usr/share/lua/5.1/clydelib/util.lua:2: in main chunk
    [C]: in function 'require'
    /usr/bin/clyde:5: in main chunk
    [C]: ?
Second curiosity... is it possible to replicate powerpill/aria's segmented, multi-threaded download capacity?

For no1: pacman "could" be uninstalled after the devs have split pacman and libalpm into different packages. Until then, you MUST have pacman in the system.

riivo · 2010-04-06 04:57:09

I recommend that if I do "clyde -Su --aur", the program should show which packages are newer in the local database than in the repository after checking AUR. For example, I currently get "warning: kernel26: local (2.6.33.2-1) is newer than core (2.6.32.10-1)", but I'd also like to see "warning: compiz-core++: local (20100405-1) is newer than AUR (20100324-1)". Would that be possible? What do others think?

thestinger · 2010-04-06 11:00:14

@pogeymanz

right now clyde builds in /tmp/clyde-username; it used to build in /tmp/clyde

you could add something like this to /etc/rc.local

su -c "ln -s /home/thestinger/clyde /tmp/clyde-thestinger" thestinger

with that you can pick another dir for it to build them in - I don't think it's really worth adding a feature (but it wouldn't hurt)

mounting /tmp as ramfs or tmpfs is a great idea because that's where things are usually compiled

Last edited by thestinger (2010-04-06 11:03:01)

pano · 2010-04-06 16:38:19

hi

Recently returned to Arch Linux, and I was looking for a yaourt replacement, since it is not maintained anymore.
Clyde looks very nice so far!
The only thing I am missing is support for translations/locales. Is it planned/possible to implement this?

Thanks! :-)

Kiwi · 2010-04-06 17:09:14

Hmm.

With respect to locales, Clyde already has pretty much full support them to the extent that Pacman does. All you need to do is copy the right locale files that Pacman installs to the right spot...get on Ghost1227s case to make it install them, he is in charge of the Makefile and PKGBUILD.

I should be making the tmp directory adjustable soon, I meant to do that this weekend but did not get to it.

Uh, yeah, do not remove Pacman. Even though Clyde does not rely on Pacman, it does rely on libalpm, which is only shipped with Pacman. You can probably fix by rebuilding Clyde if you did not figure that out yet.

I will probably be changing the way configs are handled due to a few people complaining all the time. Exactly when or how is undetermined. I like it how it is so...I will just have to find some way to compromise that both the users and I can settle on. I use Clyde full-time so what is the point of making it a way that I do not like it? That just seems silly. I would like people to like it but not at the cost of me not, if I do not then I lose motivation to develop at all and everyone loses....

And no, it would not be easier, at least not from a development standpoint, it will be a pita. Which is a big reason I have not changed it yet, in addition to that I do like it how it is.

And yes to --devel, that will probably come after I get --aur a bit more smooth and fix a few outstanding bugs in that and some other places that are annoying me to have.

In the works are plans to be less annoying with editing stuff via config options and cli flags as well as a little less verbose in some places with -q flag.

Remember, I am just one guy with a life who goes to university full time and spends at least two and a half hours driving every day, I only have limited amounts of time and energy to work on Clyde and such, it is not like I get paid to do this...I do it for fun and the positive attention.

On a related note, this stuff takes a lot of time. Yaourt was not born and mature overnight...and frankly I had to do a ton more work on Clyde to get it to the state it is now than the Yaourt developers did. Remember that I had to re-implement all of Pacman as well as write the bindings to libalpm, which is about 2600 lines of C atm, and C is not my forte. (the Lua part of Clyde is over 5300 lines). I do think Clyde is pretty close to the same level of features as Yaourt already and is way younger. I would say that is quite an accomplishment in its own right.

alterecco · 2010-04-06 18:51:20

I for one salute your work. Keep it up, but take your time

Clyde has already replaced pacman and offshots for all my package needs.

pano · 2010-04-06 19:03:12

Kiwi wrote:

Hmm.
With respect to locales, Clyde already has pretty much full support them to the extent that Pacman does. All you need to do is copy the right locale files that Pacman installs to the right spot...get on Ghost1227s case to make it install them, he is in charge of the Makefile and PKGBUILD.

I see
I'll get in contact with him :-)
Locally I now have clyde running in German :-P (even though there are some strings not localized, since they do not appear in the pacman.po)

Last edited by pano (2010-04-06 19:04:20)

Daenyth · 2010-04-06 19:21:23

It shouldn't be exceptionally difficult to copy/tweak the translation part of the pacman source tree.

cool · 2010-04-06 23:08:30

Updated clyde to latest git version, using clyde itself. recursion at its best:D

dell $ clyde clyde
1 aur/clyde-git 20100401-1 [installed] (130)
    Next-generation libalpm/makepkg wrapper.
==>  Enter #'s (separated by blanks) of packages to be installed
==>  ------------------------------------------------------------
==> 1
:: clyde-git package not found, searching for group...
:: clyde-git group not found, searching AUR...                                                                               
                                                                                                                             
==> Installing the following packages from AUR                                                                               
Targets (1): clyde-git                                                                                                       

==> Proceed with installation? [Y/n] y
==> Downloading clyde-git.tar.gz
                                                                                                                             
    ( Unsupported package from AUR: Potentially dangerous! )                                                                 
==> Edit the PKGBUILD (highly recommended for security reasons)? [Y/n] n
==> Determining latest git revision...
  -> Version found: 20100407
==> Making package: clyde-git 20100407-1 x86_64 (Wed Apr  7 04:34:41 IST 2010)
==> Checking Runtime Dependencies...
==> Checking Buildtime Dependencies...
==> Retrieving Sources...
==> Extracting Sources...
==> Entering fakeroot environment...
==> Starting build()...
==> Connecting to GIT server....
Initialized empty Git repository in /tmp/clyde/clyde-git/clyde-git/src/clyde/.git/
remote: Counting objects: 695, done.
remote: Compressing objects: 100% (693/693), done.
remote: Total 695 (delta 474), reused 0 (delta 0)
Receiving objects: 100% (695/695), 165.01 KiB | 54 KiB/s, done.
Resolving deltas: 100% (474/474), done.
==> GIT checkout done or server timeout
==> Starting make...
Initialized empty Git repository in /tmp/clyde/clyde-git/clyde-git/src/clyde-build/.git/
gcc -Wall -W -O2 -fPIC  -lalpm `pkg-config --cflags lua` -shared -o lualpm.so lualpm.c -pedantic -D_FILE_OFFSET_BITS=64 -std=c99 -D_GNU_SOURCE
gcc -Wall -W -O2 -fPIC  `pkg-config --cflags lua` -shared -o clydelib/utilcore.so clydelib/utilcore.c -pedantic -D_FILE_OFFSET_BITS=64 -std=c99 -D_GNU_SOURCE
gcc -Wall -W -O2 -fPIC  -shared -o clydelib/signal.so clydelib/lsignal.c
clydelib/lsignal.c: In function 'sighook':
clydelib/lsignal.c:167: warning: unused parameter 'ar'
clydelib/lsignal.c: In function 'l_signal':
clydelib/lsignal.c:231: warning: 'sig' may be used uninitialized in this function
install -Dm755 lualpm.so /tmp/clyde/clyde-git/clyde-git/pkg/usr/lib/lua/5.1/lualpm.so
gcc -Wall -W -O2 -fPIC  -lalpm `pkg-config --cflags lua` -shared -o lualpm.so lualpm.c -pedantic -D_FILE_OFFSET_BITS=64 -std=c99 -D_GNU_SOURCE
install -Dm755 clyde /tmp/clyde/clyde-git/clyde-git/pkg/usr/bin/clyde
install -dm755 /tmp/clyde/clyde-git/clyde-git/pkg/usr/share/lua/5.1/clydelib
install -Dm755 clydelib/utilcore.so /tmp/clyde/clyde-git/clyde-git/pkg/usr/lib/lua/5.1/clydelib/utilcore.so
install -Dm755 clydelib/signal.so /tmp/clyde/clyde-git/clyde-git/pkg/usr/lib/lua/5.1/clydelib/signal.so
install -Dm644 clydelib/*.lua /tmp/clyde/clyde-git/clyde-git/pkg/usr/share/lua/5.1/clydelib/
install -Dm644 man/clyde.8 /tmp/clyde/clyde-git/clyde-git/pkg/usr/share/man/man8/clyde.8
==> Tidying install...
  -> Purging other files...
  -> Compressing man and info pages...
  -> Stripping debugging symbols from binaries and libraries...
==> Creating package...
  -> Generating .PKGINFO file...
  -> Compressing package...
==> Leaving fakeroot environment.
==> Finished making: clyde-git 20100407-1 x86_64 (Wed Apr  7 04:34:50 IST 2010)
loading package data...
checking dependencies...
(1/1) checking for file conflicts                  [###################################################################] 100%
(1/1) upgrading clyde-git                          [###################################################################] 100%

Last edited by cool (2010-04-06 23:17:47)

cool · 2010-04-06 23:14:23

thestinger wrote:

mounting /tmp as ramfs or tmpfs is a great idea because that's where things are usually compiled

True in most conditions.

But what if you are building from VCS repo like git or svn. user might might want save downloaded tree/trunk for latter use. because /tmp is erased. you will have to download yet again, whereis you can just update ONLY what has changed.users should be a given a chance to choose.

Specially true for building packages that use git source(git gives you full tree), because the are pretty large. to downloading them again every time you upgrade will utter waste of time and bandwidth

Last edited by cool (2010-04-06 23:15:07)

quarkup · 2010-04-07 16:36:54

cool wrote:

thestinger wrote:
mounting /tmp as ramfs or tmpfs is a great idea because that's where things are usually compiled
True in most conditions.
But what if you are building from VCS repo like git or svn. user might might want save downloaded tree/trunk for latter use. because /tmp is erased. you will have to download yet again, whereis you can just update ONLY what has changed.users should be a given a chance to choose.

Specially true for building packages that use git source(git gives you full tree), because the are pretty large. to downloading them again every time you upgrade will utter waste of time and bandwidth

/tmp is erased on logoff afaik

also you can use a script when doing a logoff to backup or store the things in /tmp and recovering or retrieving them when logging in (using /etc/rc.local.shutdown and /etc/rc.local)

also depending how the package manager deals with the sources/git/svn/cvs trees it may remove them or not...

Last edited by quarkup (2010-04-07 16:38:39)

thestinger · 2010-04-07 17:09:30

@quarkup
in arch /tmp gets wiped on boot by the initscripts (when it says "removing leftover files") - but it doesn't really matter if it's wiped on shutdown/boot, the point is that it's temporary

Also, two really minor "bugs"

I've noticed clyde adds local/ in front of packages when you do clyde -Qm, which is kind of redundant (pacman doesn't do this).

Another thing is that clyde doesn't list packages by repo like pacman when you do clyde -Qs. Some people might like the fully alphabetical version more, so maybe an extra option for sorting format? I think it should stay true to the way pacman does it by default.

Last edited by thestinger (2010-04-07 17:49:10)

Berticus · 2010-04-08 06:06:37

I tried this:

% sudo clyde -Sa perl-extutils-makemaker

But it didn't search through aur. Instead, it went through the repos and reinstalled perl.

thestinger · 2010-04-08 13:52:58

Isn't clyde working as intended? The arch perl packages has perl-extutils-makemaker in the provides array.

[root@arch ~]# clyde -Sa perl-extutils-makemaker
warning: provider package was selected (perl provides perl-extutils-makemaker)
warning: perl-5.10.1-5 is up to date -- reinstalling

provides=(
perl-ansicolor=2.00 
perl-archive-extract=0.34
perl-archive-tar=1.52 
perl-autodie=2.06_01
perl-attribute-handlers=0.85
perl-autoloader=5.68
perl-b-debug=1.11
perl-b-lint=1.11
perl-base=2.14
perl-bignum=0.23
perl-cgi=3.43
perl-class-isa=0.33
perl-compress-raw-bzib2=2.020 
perl-compress-raw-zlib=2.020 
perl-constant=1.17
perl-cpan=1.9402
perl-cpanplus=0.88 
perl-db_file=1.820
perl-dprof=20080331.00
perl-data-dumper=2.124
perl-devel-ppport=3.19
perl-devel-peek=1.04
perl-digest=1.16
perl-digest-md5=2.39
perl-digest-sha=5.47 
perl-encode=2.35
perl-encoding-warnings=0.11
perl-exporter=5.63
perl-extutils-cbuilder=0.2602 
perl-extutils-command=1.16 
perl-extutils-constant=0.22 
perl-extutils-embed=1.28 
perl-extutils-install=1.54 
perl-extutils-makemaker=6.55_02
perl-extutils-manifest=1.56
perl-extutils-parsexs=2.2002
perl-file-fetch=0.20 
perl-file-path=2.07_03
perl-file-temp=0.22
perl-filter=1.37
perl-filter-simple=0.84
perl-getopt-long=2.38
perl-if=0.05
perl-io=1.25
perl-io-compress=2.020 
perl-io-zlib=1.09
perl-ipc-cmd=0.46 
perl-ipc-sysv=2.01
perl-libnet=1.22
perl-locale-codes=2.07
perl-locale-maketext=0.13
perl-locale-maketext-simple=0.18
perl-log-message=0.02
perl-log-message-simple=0.04
perl-mime-base64=3.08
perl-math-bigint=1.89
perl-math-bigint-fastcalc=0.19
perl-math-bigrat=0.22
perl-math-complex=1.56
perl-memoize=1.01_03
perl-module-build=0.340201
perl-module-corelist=2.18 
perl-module-load=0.16
perl-module-load-conditional=0.30
perl-module-loaded=0.02
perl-module-pluggable=3.9 
perl-next=0.64
perl-net-ping=2.36
perl-object-accessor=0.34 
perl-package-constants=0.02
perl-params-check=0.26
perl-parent=0.221
perl-parse-cpan-meta=1.39
perl-pathtools=3.30
perl-pod-escapes=1.04 
perl-pod-latex=0.58
perl-pod-parser=1.37
perl-pod-perldoc=3.14_04
perl-pod-simple=3.07 
perl-podlators=2.2.2
perl-safe=2.18
perl-scalar-list-utils=1.21
perl-selfloader=1.17
perl-shell=0.72_01
perl-storable=2.20
perl-switch=2.14
perl-sys-syslog=0.27
perl-term-cap=1.12
perl-term-ui=0.20 
perl-test=1.25_02
perl-test-harness=3.17
perl-test-simple=0.92
perl-text-balanced=2.0.0
perl-text-parsewords=3.27
perl-text-soundex=3.03
perl-text-tabs+wraps=2009.0305
perl-thread-queue=2.11
perl-thread-semaphore=2.09
perl-threads=1.72
perl-threads-shared=1.29
perl-tie-file=0.97_02
perl-tie-refhash=1.38
perl-time-hires=1.9719
perl-time-local=1.1901
perl-time-piece=1.15
perl-unicode-collate=0.52
perl-unicode-normalize=1.03
perl-version=0.77 
perl-win32=0.39
perl-win32api-file=0.1101
perl-xsloader=0.10
perlio-via-quotedprint=0.06
)

scio · 2010-04-09 13:29:04

Just wanted to add, I love clyde!
After this semester ends, I might be able to start hacking on some of the minor requests and bugs people find.
Between WoW addons and AwesomeWM, I've started to get used to lua but I'm still new to the internals of libalpm.
Hopefully I'll be able to make some contributions.

btouellette · 2010-04-10 04:23:15

aeosynth wrote:

[request] --noedit option. I want clyde to wait for me to confirm installation, but once I've done that, I don't want it to repeatedly ask me to edit pkgbuilds.

This would be great! I tried --noconfirm but am a lot more wary about installing packages without double checking than of not looking at PKGBUILDS and I can only do both or neither.

b4283 · 2010-04-11 04:02:03

Is there plan to add support for different compressors other than standard gzip ?
e.g. pigz for parallel gzip, pbzip2 for parallel bzip2.
I'm sure these tools will lightspeed up the finialization process of making a package.

zoqaeski · 2010-04-11 10:34:45

btouellette wrote:

aeosynth wrote:
[request] --noedit option. I want clyde to wait for me to confirm installation, but once I've done that, I don't want it to repeatedly ask me to edit pkgbuilds.
This would be great! I tried --noconfirm but am a lot more wary about installing packages without double checking than of not looking at PKGBUILDS and I can only do both or neither.

How about something similar to the view/edit/backup/confirm/skip/abort query that Xyne's Bauerbill has? IMO it is heaps better than the yaourt-style query that Clyde currently uses.

That being said, great work Kiwi and Ghost!

shining_grin · 2010-04-11 16:26:29

Really cool work dude!!!!
Installed just now from AUR, no problems at all, great work!!!
I really appreciated the automatic configuration based on pacman.conf.

I think you deserve also some appreciation for your work, not only feature requests and bugs here.

keep it up!

Howitzer · 2010-04-11 20:33:14

Wow. I'm really impressed with Clyde. Does everything for which I used packer or yaourt, but then -way- faster. Nice work!

Arch Linux

#201 2010-04-04 17:26:55

Re: Clyde - A better libalpm/makepkg wrapper

#202 2010-04-04 17:38:12

Re: Clyde - A better libalpm/makepkg wrapper

#203 2010-04-04 17:54:30

Re: Clyde - A better libalpm/makepkg wrapper

#204 2010-04-04 19:41:38

Re: Clyde - A better libalpm/makepkg wrapper

#205 2010-04-06 00:26:28

Re: Clyde - A better libalpm/makepkg wrapper

#206 2010-04-06 00:38:20

Re: Clyde - A better libalpm/makepkg wrapper

#207 2010-04-06 04:57:09

Re: Clyde - A better libalpm/makepkg wrapper

#208 2010-04-06 11:00:14

Re: Clyde - A better libalpm/makepkg wrapper

#209 2010-04-06 16:38:19

Re: Clyde - A better libalpm/makepkg wrapper

#210 2010-04-06 17:09:14

Re: Clyde - A better libalpm/makepkg wrapper

#211 2010-04-06 18:51:20

Re: Clyde - A better libalpm/makepkg wrapper

#212 2010-04-06 19:03:12

Re: Clyde - A better libalpm/makepkg wrapper

#213 2010-04-06 19:21:23

Re: Clyde - A better libalpm/makepkg wrapper

#214 2010-04-06 23:08:30

Re: Clyde - A better libalpm/makepkg wrapper

#215 2010-04-06 23:14:23

Re: Clyde - A better libalpm/makepkg wrapper

#216 2010-04-07 16:36:54

Re: Clyde - A better libalpm/makepkg wrapper

#217 2010-04-07 17:09:30

Re: Clyde - A better libalpm/makepkg wrapper

#218 2010-04-08 06:06:37

Re: Clyde - A better libalpm/makepkg wrapper

#219 2010-04-08 13:52:58

Re: Clyde - A better libalpm/makepkg wrapper

#220 2010-04-09 13:29:04

Re: Clyde - A better libalpm/makepkg wrapper

#221 2010-04-10 04:23:15

Re: Clyde - A better libalpm/makepkg wrapper

#222 2010-04-11 04:02:03

Re: Clyde - A better libalpm/makepkg wrapper

#223 2010-04-11 10:34:45

Re: Clyde - A better libalpm/makepkg wrapper

#224 2010-04-11 16:26:29

Re: Clyde - A better libalpm/makepkg wrapper

#225 2010-04-11 20:33:14

Re: Clyde - A better libalpm/makepkg wrapper

Board footer