curious...

mpie · 2005-09-22 22:29:05

Just wondering if there is a way to pass the current contents of pacman
(packages installed) to makeworld, if you wanted to rebuild only waht you had installed with just one command.
I know you can do an abs directory at a time, but if there are packages you dont have installed, you have to sift them out. so you have to manually install what you want. you can pass the install option straight to makeworld but this is not good as it would be all packages.

for example if you were running makeworld -c -i -b /base

you get both lilo and grub... take the -i option out and you then have to run packman -U every-bloody-individual.pkg.tar.gz..

this not a flame or derogitory in any manner just something that may be of use to some people, or there may be an option I've missed

T-Dawg · 2005-09-22 23:38:40

install srcpac and do:

pacman -Q | cut -d' ' -f1 | paste -s | sed 's|s| |g' >filelist
srcpac -Sby `cat filelist`

mpie · 2005-09-23 05:09:07

thank you...

if there mas nothing from the aur installed that would have worked perfectly

it just stopped as it cant find those packages but perfect for a base install

T-Dawg · 2005-09-23 06:06:56

It would be nice if there was this kind of functionality in makepkg...

try this as a script:

#!/bin/bash
pacman -Q | cut -d' ' -f1 | paste -s | sed 's|s| |g' >filelist
for e in `cat filelist`; do 
search=`find /var/abs/ -type d -name $e`
[ ! -z $search ] && echo $e >>doable
done
srcpac -Sby `cat doable`

mpie · 2005-09-23 09:26:52

will try this tonight and let you know

bardo · 2005-09-23 15:44:49

I asked to implement in pacman something similar, a "locally built" flag, so that you can recompile all and only the packages you have installed, but you haven't rebuilt from source. It would rebuild everything that has been installed from binaries, but not other software.

You can check this flyspray task: http://bugs.archlinux.org/index.php?do=details&id=3146
...and comment it, of course

phrakture · 2005-09-23 16:01:07

bardo wrote:

I asked to implement in pacman something similar, a "locally built" flag, so that you can recompile all and only the packages you have installed, but you haven't rebuilt from source. It would rebuild everything that has been installed from binaries, but not other software.
You can check this flyspray task: http://bugs.archlinux.org/index.php?do=details&id=3146
...and comment it, of course

srcpac does this already - it does not belong in pacman, as pacman knows nothing about abs itself. That's like saying that the pistons in my car's engine should control my CD player - they're part of the same unit, but unrelated.

If you use srcpac all the time (it is a wrapper around pacman, accepting pacman's normal commands), "srcpac -Syu" will detect what you've built with scrpac and what you installed via pacaman, and will rebuild it. Please note that you need to configure srcpac.conf properly.

cactus · 2005-09-23 16:36:42

so that's why my cd player has been acting up.
/me raises the hood on his car and beats on the engine block with a wrench

bad engine....bad

T-Dawg · 2005-09-23 16:41:57

also note doing srcpac -S package or pacman -S package after building it previously from source using srcpac -Sb package, will give you corruption errors (The -S switch to srcpac is actually doing a pacman -S). The reason for the error is becuase srcpac moves the built package into pacman's cache folder, so the database sums are going to differ from your built package (repo sums versus you built sums). I filed a bug report about this a while back and jason knows about. I found a temporary fix however, which was to hack srcpac to move the built package into its one designated cache folder (/var/cache/srcpac) instead of pacman's which solved the corruption errors, but won't reinstall your built version of it, only pacman's repo version.

bardo · 2005-09-23 17:42:17

phrakture wrote:

srcpac does this already - it does not belong in pacman, as pacman knows nothing about abs itself. That's like saying that the pistons in my car's engine should control my CD player - they're part of the same unit, but unrelated.

I didn't know that pacman and abs should be two separate entities with no contact points. I liked Arch much more two minutes ago
Being serious, I think that abs and pacman integrate each other, that's what makes Arch debian or gentoo, when you choose it to be. If they don't talk to each other, your system is not fully self-aware, and you have to use other tools to make this binding. Because you need to bind them, don't you?

phrakture wrote:

If you use srcpac all the time (it is a wrapper around pacman, accepting pacman's normal commands), "srcpac -Syu" will detect what you've built with scrpac and what you installed via pacaman, and will rebuild it. Please note that you need to configure srcpac.conf properly.

I didn't know this one, thanks for sharing
Still, it has the issue I pointed out above: srcpac is not in arch's "standard components" as pacman or the abs, I see it as some kind of "workaround"...
Well, all srcpac does could be implemented with a single flag in pacman (src/bin), and you need to make a wrapper out of it... To me, it's a waste of work.

My 2 cents

cmp · 2005-09-23 18:08:47

as far as I know pacman only qualifies for core functionality by purpose. I guess it's the archway to only implement a minimal core and let the user build his own system around it.

phrakture · 2005-09-23 18:09:53

bardo wrote:

I didn't know that pacman and abs should be two separate entities with no contact points. I liked Arch much more two minutes ago
Being serious, I think that abs and pacman integrate each other, that's what makes Arch debian or gentoo, when you choose it to be. If they don't talk to each other, your system is not fully self-aware, and you have to use other tools to make this binding. Because you need to bind them, don't you?
...
Still, it has the issue I pointed out above: srcpac is not in arch's "standard components" as pacman or the abs, I see it as some kind of "workaround"...
Well, all srcpac does could be implemented with a single flag in pacman (src/bin), and you need to make a wrapper out of it... To me, it's a waste of work.

I can tell you're not a developer. But from a code perspective, coupling things causes so many headaches it's rediculous. It's going to be easier to to make 3 apps "mv, cp, ls" than to make one app which does all those with flags (ala busybox).

This distinction is a primary unix philosophy. One that linux is starting to lose. The philosophy is: do one thing, and do it as good as you can, ignoring all other things. There are technologies typically called "glue code" to handle the details... "cp" does one thing. It copies. Well. If you want to do something more bizarre with it? "cp a b && cat b >> a && mv a b2" - ala bash "glue"

To show you how complicated things like this can get: go ahead an install busybox and try recursively moving a directory... the first error you get is "cannot move .. to blah" and it all goes downhill from there... i.e. don't do that in busybox - you lose files. Obviously coupling "mv" with other programs was such a good idea.... /me sighs.

Scripts are not workarounds, they are solutions. Did you know makepkg is a script just like srcpac (though one is bash, one is python)? Did you know that namcap is also a script? Did you know it is simply a glue-code layer on top of "ldd" and things like that? Did you know the developers use namcap everyday? And for the record, both namcap and srcpac were written by the same person. As much as you want to say it's a "workaround", that then forces everything *but* pacman to be a workaround... makepkg, namecap, srcpac, pacman-optimize, etc

mpie · 2005-09-23 18:13:22

Penguin wrote:

It would be nice if there was this kind of functionality in makepkg...
try this as a script:
#!/bin/bash
pacman -Q | cut -d' ' -f1 | paste -s | sed 's|s| |g' >filelist
for e in `cat filelist`; do 
search=`find /var/abs/ -type d -name $e`
[ ! -z $search ] && echo $e >>doable
done
srcpac -Sby `cat doable`

....

thanks saved as treebuild and now doing its thing, I expect it to take some time, will post results back

T-Dawg · 2005-09-23 18:21:45

if you run into a package that wont build for some reason and it quits you can do:

 cat doable | grep -n packagethatfailed

that'll give you the line number, then do:

sed -e '1,<numberspitbackfromgrep>d' -i doable

that'll delete all the lines(package entries) from the beginning up until the failed package. That way you can do:

srcpac -Sby `cat doable`

from where you left off at instead of running the script again and re-doing it all over again.

mpie · 2005-09-23 18:41:29

this is greatly appreciated, no hitches yet...

and fixes available before there are problems.. lol that's a first

mpie · 2005-09-23 18:58:28

first failure...

habak from fvwm url changed since added to abs as 404:not found error

not a problem run sed fix and off we go again, 127 packages done 670 to go !!

but still will have completely moved to gcc4.00 then

bardo · 2005-09-23 19:01:19

DISCLAIMER: all I wrote is IMVHO, and is not intended to sound arrogant as it could. I hope you want flag me as a troll

phrakture wrote:

I can tell you're not a developer. But from a code perspective, coupling things causes so many headaches it's rediculous. It's going to be easier to to make 3 apps "mv, cp, ls" than to make one app which does all those with flags (ala busybox).
This distinction is a primary unix philosophy. One that linux is starting to lose. The philosophy is: do one thing, and do it as good as you can, ignoring all other things.

I'm a dev, just a very newbie one. But before interesting in development, I've been using unix for years, I know it's philosophy and I think it's the best one. I know it's easier to make different apps for small jobs, but I think that's not the point in this discussion. Here we are talking about different things, you are pointing out the role of glue code, which srcpac surely is, and I'm not saying it is bad. I was proposing an underlying change not in the software, but in the way information about packages is stored.
Think it like a stacked structure: you have this informations stored at the base. Then, over it, you have basic tools, like pacman and the ones composing the abs. The third layer contains software like srcpac, that is nothing but a glue in this pyramid. You could grow the pyramid to an infinity of layers, as wide as you need, but there is one thing that will never change: the base will be composed of only one element, that is the information that your software manages.

Taken this, it is obvious that if you change a layer of the stack there are two other layers involved, the upper one and the lower one (only the upper one if you're talking of the base). So, if you modify packages' info, you have to adapt to this change all the software that directly accesses it.

phrakture wrote:

Scripts are not workarounds, they are solutions. Did you know makepkg is a script just like srcpac (though one is bash, one is python)? Did you know that namcap is also a script? Did you know it is simply a glue-code layer on top of "ldd" and things like that? Did you know the developers use namcap everyday? And for the record, both namcap and srcpac were written by the same person. As much as you want to say it's a "workaround", that then forces everything *but* pacman to be a workaround... makepkg, namecap, srcpac, pacman-optimize, etc

In this case, I think a script is a workaround, because it solves the problem from the wrong point of view. From the top, instead than from the bottom, if we want to keep the pyramid's metaphore.
Anyway, It's not true to say that the "srcpac way" looks at the problem only from the top, because it couldn't keep track of what was recompiled and what wasn't, so srcpac adds some other data to the base of the pyramid, but this data is accessible only to srcpac itself and overlying layers, not to the middle one, where pacman stands. Srcpac isn't glue code anymore, since it adds new features.
I see this as a flaw, and I thought that a way to correct it is to integrate srcpac's additional data into the already existing ones.

About other affirmations, I don't understand why you got so mad (if I caught it right). I actually know all those softwares are scripts, and I read some of the codes. I maintain a bunch of packages in the AUR, and I know what namcap is, I use it to make sure my builds have the right deps.
If you don't read my name everywhere, it doesn't mean that I don't do anything for the community, or that I don't know anything about Arch's tools.
I'm just asking, now that you know all this, why shouldn't I think this way? Isn't it just another opinion? Or are there some reasons why it is completely wrong?

mpie · 2005-09-23 19:36:50

so far 4 fails....

logrotate, mplayer,( mpg321 and habak two fails urls~) mplayer beacuse you need to instruct it to continue wth an unsupported gccversion.

not too bad though and it opens the door for cross-compiling a bit too..

although at the moment this is just a test on my own box that is i686

mpie · 2005-09-24 04:50:41

success....

two other failures but thats it and again they were for ropey urls..

many thanks penguin

IsSuE · 2006-05-06 13:44:50

is srcpac still in developement or has its developer quit?
srcpac is a really nice thing, but it has some bugs in that really are annoying, as penguin stated a few lines above. Or is there a similar project?

T-Dawg · 2006-05-06 18:26:53

IsSuE wrote:

is srcpac still in developement or has its developer quit?
srcpac is a really nice thing, but it has some bugs in that really are annoying, as penguin stated a few lines above. Or is there a similar project?

I made a bug report on fly spray about the corruption errors but it never got looked into.
I actually wrote something similar to srcpac that looks at abs instead of pacman's db which allows you to update your entire system once a package is in cvs. It also uses aurbuild's menu to veiw/edit the build files and builds as user with fakeroot and sudo to install and all that jazz I may post it in user-contributions someday...

napoleon · 2006-05-27 21:05:02

Penguin wrote:

It would be nice if there was this kind of functionality in makepkg...
try this as a script:
#!/bin/bash
pacman -Q | cut -d' ' -f1 | paste -s | sed 's|s| |g' >filelist
for e in `cat filelist`; do 
search=`find /var/abs/ -type d -name $e`
[ ! -z $search ] && echo $e >>doable
done
srcpac -Sby `cat doable`

I just tried to use this script but it gives me the follwing:

[napoleon@archlinux ~]$ sudo ./allsrcpac
Password:
./allsrcpac: line 5: [: /var/abs/.sup/arch: binary operator expected

Help please.

neotuli · 2006-05-28 03:07:32

IsSuE wrote:

is srcpac still in developement or has its developer quit?
srcpac is a really nice thing, but it has some bugs in that really are annoying, as penguin stated a few lines above. Or is there a similar project?

Xentac accepts patches

T-Dawg · 2006-05-28 10:40:11

napoleon wrote:

Penguin wrote:
It would be nice if there was this kind of functionality in makepkg...
try this as a script:
#!/bin/bash
pacman -Q | cut -d' ' -f1 | paste -s | sed 's|s| |g' >filelist
for e in `cat filelist`; do 
search=`find /var/abs/ -type d -name $e`
[ ! -z $search ] && echo $e >>doable
done
srcpac -Sby `cat doable`
I just tried to use this script but it gives me the follwing:
[napoleon@archlinux ~]$ sudo ./allsrcpac
Password:
./allsrcpac: line 5: [: /var/abs/.sup/arch: binary operator expected
Help please.

try putting it in a for loop. for s in $search; do [ ! -z $s ] && echo $e >>doable; break; done

napoleon · 2006-05-28 12:55:38

I bet from the following question you will figure that i am not a programmer anyway, thanks so far. I tried your suggestion ie

#!/bin/bash
pacman -Q | cut -d' ' -f1 | paste -s | sed 's|s| |g' >filelist
for e in `cat filelist`; do
search=`find /var/abs/ -type d -name $e`
for s in $search; do [ ! -z $s ] && echo $e >>doable; break; done
srcpac -Sby `cat doable`

and now it give me the following error:

[napoleon@archlinux ~]$ sudo ./allsrcpac
./allsrcpac: line 7: syntax error: unexpected end of file

thanks

Arch Linux

#1 2005-09-22 22:29:05

curious...

#2 2005-09-22 23:38:40

Re: curious...

#3 2005-09-23 05:09:07

Re: curious...

#4 2005-09-23 06:06:56

Re: curious...

#5 2005-09-23 09:26:52

Re: curious...

#6 2005-09-23 15:44:49

Re: curious...

#7 2005-09-23 16:01:07

Re: curious...

#8 2005-09-23 16:36:42

Re: curious...

#9 2005-09-23 16:41:57

Re: curious...

#10 2005-09-23 17:42:17

Re: curious...

#11 2005-09-23 18:08:47

Re: curious...

#12 2005-09-23 18:09:53

Re: curious...

#13 2005-09-23 18:13:22

Re: curious...

#14 2005-09-23 18:21:45

Re: curious...

#15 2005-09-23 18:41:29

Re: curious...

#16 2005-09-23 18:58:28

Re: curious...

#17 2005-09-23 19:01:19

Re: curious...

#18 2005-09-23 19:36:50

Re: curious...

#19 2005-09-24 04:50:41

Re: curious...

#20 2006-05-06 13:44:50

Re: curious...

#21 2006-05-06 18:26:53

Re: curious...

#22 2006-05-27 21:05:02

Re: curious...

#23 2006-05-28 03:07:32

Re: curious...

#24 2006-05-28 10:40:11

Re: curious...

#25 2006-05-28 12:55:38

Re: curious...

Board footer