Closed GoogleCodeExporter closed 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
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
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
[deleted comment]
(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
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
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
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
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
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
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
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
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
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
Original issue reported on code.google.com by
artour...@gmail.com
on 3 Nov 2009 at 11:14