mhertz commented 13 years ago

Please check the latest posts in the arch forum's packer thread for more info...

Also, could you please consider adding a -Syuu allowed option too, since in [testing] then packages from time to time are buggy and gets downgraded, but packer will leave the buggy packages with -Syu, instead of downgrading them...

I always used -Syuu to upgrade when I was using pacman for that, instead of packer

bruenig commented 13 years ago

What would I need to do to add this, just when someone does -Suu (or -Syuu) have pacman run that instead of -Syu, but have the aur side of things behave the same?

On Sun, Jul 10, 2011 at 12:51 AM, mhertz reply@reply.github.com wrote:

Please check the latest posts in the arch forum's packer thread for more info...

Also, could you please consider adding a -Syuu allowed option too, since in [testing] then packages from time to time are buggy and gets downgraded, but packer will leave the buggy packages with -Syu, instead of downgrading them...

I always used -Syuu to upgrade when I was using pacman for that, instead of packer

Reply to this email directly or view it on GitHub: https://github.com/bruenig/packer/issues/39

mhertz commented 13 years ago

Yes, exactly! And thank you so much for considering this, mate!

Btw, I know i'm stretching it, but how do you feel about adding customizepkg(bash script) as optdepends to packer, like I wrote in the arch forum's packer thread? I posted a one-line patch which could add the support(tested!)... (Actually I just got brisbin to add it to aurget yesterday in his latest git commit)...

Thanks again for the -Syuu consideration!

Martin.

Edit: Sorry I forgot one thing: --devel only upgrades devel-packages, whereas aurget/yaourt upgrades devel-packages and normal ones... I think the later approach makes much better sence, so we don't need to run packer twice after eachother; with and without --devel...

bruenig commented 13 years ago

I added the -Syyuu stuff. In order to avoid setting up speed-killing
parsing (since it has gotten to the point where any mixing up of the
following would be permitted: Suuyy Suyy Suuy Suy Suu Su), I just decided
to let anything matching -S*u flow through to pacman. If you fuck up by
putting wrong letters in there, pacman will catch it anyways.

You are sure that the customizepkg stuff only requires that one line? I
don't have any objection to that if you are sure on that.

On , mhertz
reply@reply.github.com
wrote:

Yes, exactly! And thank you so much for considering this, mate!

Btw, I know i'm stretching it, but how do you feel about adding
customizepkg(bash script) as optdepends to packer, like I wrote in the
arch forum's packer thread? I posted a one-line patch which could add the
support(tested!)... (Actually I just got brisbin to add it to aurget
yesterday in his latest git commit)...

Thanks again for the -Syuu consideration!

Martin.

Reply to this email directly or view it on GitHub:

https://github.com/bruenig/packer/issues/39#issuecomment-1541886

mhertz commented 13 years ago

Thank you so much, mate!

Yes, the customizepkg stuff works with that one line, and I have tested it. aurget uses:

if [[ -f "/etc/customizepkg.d/$Name" ]]; then display 'Calling customizepkg...' customizepkg --modify || warn 'customizepkg had a problem' fi

I don't care about the extra verboseness, and also customizepkg by itself outputs that it's applying the changes, or if it has a problem, but it's your call... Again, I really appreciate this very much!

Finally, what do you feel about letting --devel also include regular upgrades, just like aurget, yaourt etc. ? Right now with packer I have to run "packer -Syu --devel && packer -Syu" to be fully upgraded, as theres aur updates to both a regular package of mine and obviously to my git-packages... I don't see why anyone would want devel-packages upgraded without including the regular ones additionally?

bruenig commented 13 years ago

http://sprunge.us/SQZa

See if that works for customizepkg

customizepkg

if [[ -f "/etc/customizepkg.d/$1" ]] && type -p customizepkg &>/dev/null;
then echo "Applying customizepkg instructions..." customizepkg --modify fi

I added in the type -p to make sure that the command exists (it strikes me
that it is possible for someone to have uninstalled customizepkg without
getting rid of their config files that they made for it. (I can't really
test this since I don't use customizepkg however)

On , mhertz
reply@reply.github.com
wrote:

Thank you so much, mate!

Yes, the customizepkg stuff works with that one line, and I have tested
it. Also aurget uses that line, but with just added echoing "calling
customizepkg" and "|| customizepkg had a problem" after "customizepkg
--modify", but that shouldn't really be needed imho... Again, I really
appreciate this very much!

Finally, what do you feel about letting --devel also include regular
upgrades, just like aurget, yaourt etc. ? Right now with packer I have to
run "packer -Syu --devel && packer -Syu" to be fully upgraded, as theres
aur updates to both a regular package of mine and obviously to my
git-packages...

Reply to this email directly or view it on GitHub:

https://github.com/bruenig/packer/issues/39#issuecomment-1542332

mhertz commented 13 years ago

Works perfectly; thanks again!

./packer -S --noedit ratpoison-git :

Aur Targets (1): ratpoison-git

Proceed with installation? [Y/n] Applying customizepkg instructions... => removes/replaces '.\/configure --prefix=\/usr' by '.\/configure --prefix=\/usr --without-xft' in global --- ./PKGBUILD 1970-01-01 10:13:08.000000000 +0100 +++ ./PKGBUILD.custom 2011-07-10 19:33:25.934522292 +0200 @@ -36,7 +36,7 @@ cd ${startdir}/src/${_gitname}-build

./autogen.sh || return 1

./configure --prefix=/usr || return 1
./configure --prefix=/usr --without-xft || return 1 make || return 1

cd contrib ==> Determining latest git revision... [...]

Sorry for keeping bothering you, but what do you think about the --devel issue I mentioned in my previous post?

And also the: 'packer -S yaourt', which fails because it thinks there are 3 aur deps:

Aur Targets (3): package-query yaourt

bruenig commented 13 years ago

That bug was extremely difficult to run down. I apparently introduced it when I made a change to reverse the order that the aur dependencies were being stored in the aurdeps array. Should be fixed now. It along with the customizepkg changes have been committed.

I will look into the devel thing. I didn't realize it was only doing development packages to be honest (no one has ever pointed that out either). It might take a bit more refactoring though than the other changes, so it might take a bit.

On Sun, Jul 10, 2011 at 1:46 PM, mhertz reply@reply.github.com wrote:

Works perfectly; thanks again!

./packer -S --noedit ratpoison-git :

Aur Targets (1): ratpoison-git

Proceed with installation? [Y/n] Applying customizepkg instructions... => removes/replaces '.\/configure --prefix=\/usr' by '.\/configure --prefix=\/usr --without-xft' in global --- ./PKGBUILD 1970-01-01 10:13:08.000000000 +0100 +++ ./PKGBUILD.custom 2011-07-10 19:33:25.934522292 +0200 @@ -36,7 +36,7 @@ cd ${startdir}/src/${_gitname}-build

./autogen.sh || return 1

./configure --prefix=/usr || return 1

./configure --prefix=/usr --without-xft || return 1 make || return 1

cd contrib ==> Determining latest git revision... [...]

Sorry for keeping bothering you, but what do you think about the --devel issue I mentioned in my previous post?

And also the: 'packer -S yaourt', which fails because it thinks there are 3 aur deps:

Aur Targets (3): package-query yaourt

Reply to this email directly or view it on GitHub: https://github.com/bruenig/packer/issues/39#issuecomment-1542447

mhertz commented 13 years ago

Yes, the yaourt issue works fine now! Thanks you so much!

I am very sorry bruenig for stating --devel didn't include regular packages, since I now tested with installing ps_mem which is a regular aur package, where I had changed the version in the pkgbuild to a lower version, and this time --devel did pick it up, so i apologise for posting wrong info to you!

However, the reason I thought that this was the case, is that if i use --devel, then the regular package rtl8192se wont be updated, but when omiting --devel, then rtl8192se is updated???

Again im really sorry for the wrong assumption, and I am very gratefull for your great support you've provided me/community with, thanks alot!

So, my only remaining issue is that rtl8192se isn't upgraded with --devel, but only without it...

bruenig commented 13 years ago

http://aur.archlinux.org/packages/rtl8192se/PKGBUILD

devel is basically for packages that use version control systems (like git
cvs svn). The reason it needs to exist -- as I am sure you are aware -- is
because a lot of times developers just commit changes without modifying the
version number on the pkgbuild. But as you can see in the link above, the
package you are having difficulty with is actually downloading its sources
from a tarball, not a vcs.

source=("http://www.nd.edu/~pbui/scratch/aur/${pkgname}_linux_${pkgver}.tar.gz")

So devel wont work for it. The author will have to change the version
number if you are going to be able to access a new tarball anyways.

For future reference, packer takes the approach that makepkg does. It
considers something a devel package if has one of the following variables
set to something:

_darcstrunk _cvsroot _gitroot _svntrunk _bzrtrunk _hgroot

If one of those variables exists, it goes ahead and tries to update. If
none exist, then it is not a devel package, and can only be updated when
the version number of the PKGBUILD changes.

On , mhertz
reply@reply.github.com
wrote:

Yes, the yaourt issue works fine now! Thanks you so much!

I am very sorry bruenig for stating --devel didn't include regular
packages, since I now tested with installing ps_mem which is a regular
aur package, where I had changed the version in the pkgbuild to a lower
version, and this time --devel did pick it up, so i apologise for posting
wrong info to you!

However, the reason I thought that this was the case, is that if i use
--devel, then the regular package rtl8192se wont be updated, but when
omiting --devel, then rtl8192se is updated???

Again im really sorry for the wrong assumption, and I am very gratefull
for your great support you've provided me/community with, thanks alot!

So, my only remaining issue is that rtl8192se isn't upgraded with
--devel, but only without it...

Reply to this email directly or view it on GitHub:

https://github.com/bruenig/packer/issues/39#issuecomment-1542860

mhertz commented 13 years ago

We are talking besides each other, and sorry if I wasn't clear enough...

Yeah, I fully acknowledge that, but my point was that rtl8192se is a non-devel package(which was what i meant with the word "regular" in my previous post), but isn't upgraded when using --devel, but only without.

I did a debug run ie "bash -x ....." of both with and without --devel, and I believe ive found the problem:

Without --devel:

++ vercmp 2.6.0019.1207.2010-5 2.6.0019.1207.2010-1

[[ 1 -gt 0 ]]

With --devel:

++ vercmp 2.6.0019.1207.2010 2.6.0019.1207.2010-1

[[ 0 -gt 0 ]]

It seems that with --devel then pkgrl is ignored for the installed package during the vercmp step, but without --devel then pkgrl is used in the vercmp additionally...

bruenig commented 13 years ago

Oh I see what you mean now. I pushed a change. It should work now.

For the non-devel upgrades, I was relying on the 'Version:' information
provided from the aur json interface which already combines the $pkgver and
$pkgrl and feeds it to you as $pkgver-$pkgrl.

For the devel upgrades (since I source the pkgbuild right there), I just
used a shortcut and was pulling the information from the pkgbuild, but only
doing $pkgver instead of $pkgver-$pkgrl.

A quick fix though to add in that -$pkgrl

On , mhertz
reply@reply.github.com
wrote:

We are talking besides each other, and sorry if I wasn't clear enough...

Yeah, I fully acknowledge that, but my point was that rtl8192se is a
non-devel package(which was what i meant with the word "regular" in my
previous post), but isn't upgraded when using --devel, but only without.

I did a debug run ie "bash -x ....." of both with and without --devel,
and I believe ive found the problem:

Without --devel:

++ vercmp 2.6.0019.1207.2010-5 2.6.0019.1207.2010-1

[[ 1 -gt 0 ]]

With --devel:

++ vercmp 2.6.0019.1207.2010 2.6.0019.1207.2010-1

[[ 0 -gt 0 ]]

It seems that with --devel then pkgrl is ignored for the installed
package during the vercmp step, but without --devel then pkgrl is used in
the vercmp additionally...

Reply to this email directly or view it on GitHub:

https://github.com/bruenig/packer/issues/39#issuecomment-1543005

mhertz commented 13 years ago

Thanks again, mate!

However im really sorry, but I accidentally spelled the var wrongly for you, so it still dosen't work, since it's supposed to be '$pkgrel' and not '$pkgrl'...

Sorry again!

bruenig commented 13 years ago

Typo fixed. Productive day!

On , mhertz
reply@reply.github.com
wrote:

Thanks again, mate!

However im really sorry, but I accidentally spelled the var wrongly for
you, so it still dosen't work, since it's supposed to be '$pkgrel' and
not '$pkgrl'...

Sorry again!

Reply to this email directly or view it on GitHub:

https://github.com/bruenig/packer/issues/39#issuecomment-1543142

mhertz commented 13 years ago

Yeah, indeed; you've done a great job and I really appreciate your efforts!

I've just tested and everything is perfect now!

Thanks again, mate

CU, Martin.

keenerd / packer

'packer -S yaourt' fails... #39

customizepkg