Re: PPM

[prev] [thread] [next] [lurker] [Date index for 2005/08/17]

From: Jonathan Trites
Subject: Re: PPM
Date: 23:14 on 17 Aug 2005
I don't know anything about ppm, and it seems that you have already
fixed the problem, but could you uninstall 1.45 first? If it was
uninstalled and didn't exist, then maybe the install command would get
1.46 and not be confused since the 1.45 package wouldn't exist at that
point.

And yes, I know that I'm not supposed to be helpful on this list. So,
to make up for it, I hate how in firefox when a download terminates
before it is done, firefox just says that it's done and doesn't say
"download terminated unexpectedly" or some such. Since it says the
download is done, it also means I just can't click retry and have it
start over. Brilliant design choice!!! There, the forces are back in
balance.

On 8/17/05, Smylers <Smylers@xxxxxxx.xxx> wrote:
> PPM (version 3.1, if that matters) is being particularly hateful today.
> We've got a windows server which has Email::Send 1.45 on it, which is
> broken.  I wish to upgrade it to 1.46, which isn't broken.
>=20
>   C:\>ppm install Email::Send
>   Searching for 'Email::Send' returned multiple results. Using 'search'
>   instead...
>=20
>   Searching in Active Repositories
>     1. Email-Send   [1.46] Simply Sending Email
>     2. Email-Send    [1.4] Simply Sending Email
>     3. Email-Send   [1.41] Simply Sending Email
>     4. Email-Send   [1.43] Simply Sending Email
>     5. Email-Send   [1.45] Simply Sending Email
>     6. Email-Send   [1.46] Simply Sending Email
>=20
> Hmmm, a list of "multiple" results, all for the same package.  Guess
> what, it's the _latest_ version of that package I wish to install.
> Actually, _either_ of the latest versions would do, given that items 1
> and 6 in the above list are hatefully displayed the same, giving me no
> clue at all as to in what way they might differ.
>=20
> Let's give installation another go, remembering that PPM is stateful (as
> well as hateful) and that once one command has emitted a numbered list a
> following command can use those numbers to refer particular itmes:
>=20
>   C:\>ppm install 1
>   No search results to install -- use 'search' to find a package.
>=20
> Yes, but I've just used 'search' -- or rather it used it for me!
> Presumably PPM is only stateful when run as a shell, rather than with
> sub-commands directly on the command line.  But it's hateful that the
> error messages don't mention that point, and, even worse, try to goad
> you into doing something that won't work.  Let's try again:
>=20
>   C:\>ppm
>   ...
>   ppm> search Email::Send
>   Searching in Active Repositories
>     1. Email-Send   [1.46] Simply Sending Email
>     2. Email-Send    [1.4] Simply Sending Email
>     3. Email-Send   [1.41] Simply Sending Email
>     4. Email-Send   [1.43] Simply Sending Email
>     5. Email-Send   [1.45] Simply Sending Email
>     6. Email-Send   [1.46] Simply Sending Email
>   ppm> install 1
>   Package 1:
>   Note: Package 'Email-Send' is already installed.
>=20
> Yes, I know Email-Send is already installed, but package 1 in the above
> list is most definitely version 1.46, which is newer than the version
> I've installed.  Look, it'll even tell me that:
>=20
>   ppm> q Email::Send
>   Querying target 1 (ActivePerl 5.8.4.810)
>   No matches for 'Email::Send'; see 'help query'.
>=20
> At least it would if it kept track of which packages supply which
> modules, so that users could refer to modules, things they program with
> and actually want to use, in all PPM commands -- rather than hatefully
> and tantalizingly letting us use modules in some commands and forcing us
> to use packages in others:
>=20
>   ppm> q Email-Send
>   Querying target 1 (ActivePerl 5.8.4.810)
>     1. Email-Send   [1.45] Simply Sending Email
>=20
> So that's what I want to upgrade.  Let's try the upgrade command:
>=20
>   ppm> upgrade Email::Send
>   Error: package 'Email::Send' is not installed.
>=20
> So install can cope with a module name but even upgrade can't?  Hate!
>=20
>   ppm> upgrade Email-Send
>   Email-Send 1.45: up to date.
>=20
> Yes, I know that Email-Send 1.45 is up to date; what I'm wanting you to
> install is Email-Send 1.46 which you listed for me earlier!  Let's go
> back to that list and try to upgrade it from there:
>=20
>   ppm> search Email::Send
>   Searching in Active Repositories
>     1. Email-Send   [1.46] Simply Sending Email
>     2. Email-Send    [1.4] Simply Sending Email
>     3. Email-Send   [1.41] Simply Sending Email
>     4. Email-Send   [1.43] Simply Sending Email
>     5. Email-Send   [1.45] Simply Sending Email
>     6. Email-Send   [1.46] Simply Sending Email
>   ppm> upgrade 1
>   Email-Send 1.45: up to date.
>=20
> Huh?  What?  Now, really, there's no excuse for that.
>=20
> Oh, from reading the help it transpires that upgrade only _lists_
> potential upgrades; it hatefully doesn't try to install an upgrade
> unless you give it the -install flag (not to be confused with the
> install command, above, which hatefully won't install upgrades either):
>=20
>   ppm> upgrade -install Email-Send
>   Email-Send 1.45: up to date.
>=20
> Noooo!!!
>=20
> Let's try that list again.
>=20
>   ppm> search Email::Send
>   Searching in Active Repositories
>     1. Email-Send   [1.46] Simply Sending Email
>     2. Email-Send    [1.4] Simply Sending Email
>     3. Email-Send   [1.41] Simply Sending Email
>     4. Email-Send   [1.43] Simply Sending Email
>     5. Email-Send   [1.45] Simply Sending Email
>     6. Email-Send   [1.46] Simply Sending Email
>   ppm> upgrade -install 1
>   Error: package '1' is not installed.
>=20
> So the install command can take numbers from a search list instead of
> package names; the upgrade command can take such numbers when searching
> for a package; but give the upgrade the -install flag and it suddenly
> forgets how to use these numbers?  Yer-what???
>=20
> Let's try removing the ambiguity in the above list.  PPM comes
> configured to search 2 repositories by default.  The above list looks
> suspiciously like one of those repositories has lots of versions of
> Email-Send and one only has the version I want, so if I disable the
> repository with lots there should be just the one I want left.
>=20
>   ppm> rep
>   Repositories:
>   [1] ActiveState PPM2 Repository
>   [2] ActiveState Package Repository
>=20
> Wow, those are sure good names for making absolutely clear the
> distinction between the two them.  Let's disable the first one:
>=20
>   ppm> rep off 1
>   Repositories:
>   [1] ActiveState Package Repository
>   [ ] ActiveState PPM2 Repository
>=20
> and try that search again:
>=20
>   ppm> search Email::Send
>   Searching in Active Repositories
>     1. Email-Send    [1.4] Simply Sending Email
>     2. Email-Send   [1.41] Simply Sending Email
>     3. Email-Send   [1.43] Simply Sending Email
>     4. Email-Send   [1.45] Simply Sending Email
>     5. Email-Send   [1.46] Simply Sending Email
>=20
> Ooops, chose wrong.  Let's disable that repository and enable the other
> one:
>=20
>   ppm> rep off 1
>   Repositories:
>   [ ] ActiveState Package Repository
>   [ ] ActiveState PPM2 Repository
>=20
> Hmmm, it indicates that a repository is disabled by removing its number.
> So now there's no handy way of indicating which of the disabled
> repositories I wish to enable; its name has to be typed in full.  I'm
> _so_ glad somebody redundantly put "Repository" at the end of the name
> of a package repository, in a list of package repositories, just so that
> I could type it in again:
>=20
>   ppm> rep on ActiveState PPM2 Repository
>   [1] ActiveState PPM2 Repository
>   [ ] ActiveState Package Repository
>=20
> Search again:
>=20
>   ppm> search Email::Send
>    1. Email-Send   [1.46] Simply Sending Email
>=20
> Hurrah!  No ambiguity there, let's try that upgrade:
>=20
>   ppm> upgrade -install Email-Send
>   ppm>
>=20
> That's right: nothing.  Just the PPM prompt back again.
>=20
> And no, this isn't the 'no news is good news' sense of nothing that you
> get with Unix commands, where a lack of error message indicates success.
> The installed package is still at version 1.45.
>=20
> I'm completely stumped.  I've got a package manager which can tell me
> about a package that I want, but I can't find a way of actually
> persuading it to install it.  This is ridiculous!  What on earth is the
> point of a package manager that declines to install packages that it's
> told you are available for installation?
>=20
> So What I actually did to fix Email::Send on this server is use Cpan
> Search's diff feature to view the 2 lines that have changed between 1.45
> and 1.46, then use 'WordPad' to hack those changes directly on to the
> installed module.  As a technique it doesn't scale well, but it has the
> advantage of actually working.
>=20
> Smylers
> --
> May God bless us with enough foolishness to believe that we can make a
> difference in this world, so that we can do what others claim cannot be d=
one.
>=20
>=20


--=20
And then there was the lawyer that stepped in cow manure and thought
he was melting...

Generated at 17:00 on 23 Aug 2005 by mariachi 0.52