Ponce / sbopkg.copy

Automatically exported from code.google.com/p/sbopkg
1 stars 0 forks source link

Install option within package menu gove wrong package to install #33

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?
When the packages for both adobe-reader version 9.1.1, 9.1.2 and version
9.2 are available in the package folder, the adobe-reader package menu
offer the install option to install 9.1.1 and not 9.2.

I only observed this behaviour with the adobe-reader package, the other
ones I have show me the latest version available.

What is the expected output? What do you see instead?
should give the option to install the lastest package

What version of the product are you using? On what operating system?
sbopkg 0.31.0 slackware 13.0/12.0

Please provide any additional information below.

Original issue reported on code.google.com by artour...@gmail.com on 3 Nov 2009 at 11:14

GoogleCodeExporter commented 9 years ago
Thanks for the report.  We'll look into this one.

Original comment by chess.gr...@gmail.com on 5 Nov 2009 at 7:48

GoogleCodeExporter commented 9 years ago
If you temporarily move adobe-reader versions 9.1.1 and 9.1.2 out of the package
folder, does sbopkg then correctly list 9.2 as the installable package?

Original comment by chess.gr...@gmail.com on 11 Nov 2009 at 4:05

GoogleCodeExporter commented 9 years ago
hi chess,

yes is 9.2 is the only adobe-reader package available it will show it, but 
somehow
for adobe reader it always shows the smaller version:

if I have 9.1.1 9.1.2 and 9.2 it will show be 9.1.1 ...

Hope this helps

Cheers

Original comment by artour...@gmail.com on 15 Nov 2009 at 3:26

GoogleCodeExporter commented 9 years ago
[deleted comment]
GoogleCodeExporter commented 9 years ago
(comment deleted -- sorry for the noise, I'm definitely losing my familiarity 
with
sbopkg internals :-/)

Original comment by mauro.giachero@gmail.com on 15 Jan 2010 at 10:33

GoogleCodeExporter commented 9 years ago
Thanks for the bug report, but I can't reproduce this. What are the actual
path/filenames you have? When I touch

/var/cache/sbopkg/pkgs/adobe-reader-9.1.1-i486-1_SBo.tgz
/var/cache/sbopkg/pkgs/adobe-reader-9.1.2-i486-1_SBo.tgz
/var/cache/sbopkg/pkgs/adobe-reader-9.2-i486-1_SBo.tgz

I get

Install     adobe-reader-9.2-i486-1_SBo.tgz

as expected.

Original comment by slakmagik@gmail.com on 29 Jan 2010 at 7:17

GoogleCodeExporter commented 9 years ago
I just did the same test as slakmagik and got the same (correct) result:
adobe-reader-9.2.

Chalk it up to those damned cosmic rays again?

Original comment by chess.gr...@gmail.com on 1 Feb 2010 at 2:05

GoogleCodeExporter commented 9 years ago
Actually, I think I found what the problem is:

I get it when the version of the package includes _something. In the case of the
adobe reader package the full name is adobe-reader-9.*_enu-i486-1_SBo.tgz.

if you add the _enu to the version name, I get the problem I described. If I 
remove
the _enu, then sbopkg behaves properly.

I discovered I get the same behaviour with virtualbox-kernel{,-addons} packages.

Hope this sheds some light.

Cheers

Greg

Original comment by artour...@gmail.com on 2 Feb 2010 at 8:57

GoogleCodeExporter commented 9 years ago
Yes it does, thank you. With _enu in the filenames, I can reproduce it. And 
that's
indeed why - now it's just a matter of figuring out what to do about it. :)

Original comment by slakmagik@gmail.com on 2 Feb 2010 at 11:19

GoogleCodeExporter commented 9 years ago
line 1141 of 0.31.1 (should be 1145 of trunk) reads

CURPACKAGE=$(head -n 1 <<< "$CURPACKAGE")

As long as changing 'head' to 'tail' doesn't cause unwanted side-effects with 
other
packages, that should fix it. I'll do more testing but if you wanted to try it 
and
let us know how it goes, that would be great.

Original comment by slakmagik@gmail.com on 3 Feb 2010 at 12:50

GoogleCodeExporter commented 9 years ago
Hi Slakmagick,

it does indeed seem to fix the problem. I have tried to find cases where it 
could
fail but so far I can't.

examples of case I tried is when the bit after the underscore is relevant to the
version, as it is the case for the flash-player-plugin package:
10.0_r32 < 10.0_r42
10.0_r32 < 10.1_r30

it all seems to work as expected.

in an additional note about version detection, I just saw that when 
opencv-1.1pre1 is
install, looking for potential update doesn't pick up the fact that the lastest 
SBo
version is opencv-1.1.0, not even as a downgrade. (this is the case on both 
0.31.0
and latest trunk.) if you want me to file another bug report for that let me 
know.

Original comment by artour...@gmail.com on 3 Feb 2010 at 2:02

GoogleCodeExporter commented 9 years ago
Another possible solution might be to add the -r switch to the ls in line 1128:

OUTPUTFILES=$(ls -r1 $OUTPUT)

I have not thought through all the possible issues with either solution, though.

And about opencv, well, that's just annoying.  :-)  It's obviously tied to use 
of
'pre1' in the earlier version.

Original comment by chess.gr...@gmail.com on 3 Feb 2010 at 2:20

GoogleCodeExporter commented 9 years ago
Actually, there's an error in the opencv package - the SlackBuild still 
references
1.1pre1 and the info file's DOWNLOAD points there, too. Only the VERSION of the 
info
files says '1.1.0'.

And, Greg, just a note on the previous problem where I should have been 
clearer: it's
not the underscore, as such, that causes the adobe-reader problem but the fact 
that
the VERSION is redefined in the SlackBuild, relative to the info file.

VERSION=${VERSION}_$ADOBE_LANG

So the '_enu' was the problem and allowing me to reproduce it, but it can be any
thing where the VERSION is reassigned. The mismatch was causing us to fall 
through to
the loosest match and grabbing all three adobe packages and picking one from 
them.
It's just that 'tail' was causing us to pick the wrong one. There could be cases
where the reversal would be wrong (like if VERSION was reassigned from '1.0' to 
some
dumb version string like 'beta1.0' where 1.0 was newer) but 'tail' or '-r' 
should be
right more often than 'head'. (Hope that made sense.)

Original comment by slakmagik@gmail.com on 3 Feb 2010 at 2:57

GoogleCodeExporter commented 9 years ago
r758 was committed to address this; thanks again for the report.

(I'd have noted this last night, but my net connection went out.)

Original comment by slakmagik@gmail.com on 3 Feb 2010 at 6:59