[vwnc] Checking for new version of a given package

Hi list,
            I'm looking for the following functionality: Given a list
of packages in my image I would like to launch an "update tool" that
tries to connect to all my configured repositories to look for new
versions of my packages. I would like this to be done at a "low level"
wrt the repository that I am currently connected to (i.e. querying at
the DB level and not forcing me to connect to every repository). Is
there a goodie that already implements this? In case there isn't,
could someone give me a hint on how to establish a connection and
query a repository DB for the last version of a given package, without
having to actually connect to that repository?

Thanks in advance,
                               Andrés
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

On Oct 9, 2008, at 4:49 PM, Andres Fortier wrote:

> Hi list,
>            I'm looking for the following functionality: Given a list
> of packages in my image I would like to launch an "update tool" that
> tries to connect to all my configured repositories to look for new
> versions of my packages.

An image that is configured from multiple repositories seems quite  
smelly to me. I guess I avoid it because I expect it to wreak havoc on  
prerequisites when building up from a pristine image.


I suggest you create a local repository to which your image connects  
and use the replicator tools to ensure the latest versions of third-
party packages are present in your local repository.

I find it helpful to load the replicator in a separate image - it is  
not helpful if its life cycle is dictated by whatever you do to your  
development image. Also make sure you use the Glorp based replicator,  
I understand the Store based one is suspect. (i.e. load parcel  
StoreForGlorpvWUI)



Now that your development image needs to connect to only one  
repository you can make use of the store tools like for instance the  
menu command'More recently published items'. (We found it helpful to  
add a menu item that does 'More recently published items with blessing  
 >= development').


There is one gotcha with replication you need to be aware of:
Prior to 7.6 store clients (the development images in our scenario)  
would assume that higher database id's would imply younger time  
stamps. This assumption breaks down when the repository contains  
replicated code. See also pkg 'Store-Replication support patches' in  
the public repository.


> I would like this to be done at a "low level"
> wrt the repository that I am currently connected to (i.e. querying at
> the DB level and not forcing me to connect to every repository). Is
> there a goodie that already implements this? In case there isn't,
> could someone give me a hint on how to establish a connection and
> query a repository DB for the last version of a given package, without
> having to actually connect to that repository?

See parcel StoreForGlorp :-)



>
>
> Thanks in advance,
>       Andrés
> _______________________________________________
> vwnc mailing list
> [hidden email]
> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
>


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Hi Reinout,

> An image that is configured from multiple repositories seems quite  
> smelly to me. I guess I avoid it because I expect it to wreak havoc on  
> prerequisites when building up from a pristine image.

Well, as a simple example, consider having my local repository and
Cincom Public one. If I'm using a couple of packages loaded from the
public repository, even if I replicate them on my local store there is
no way (at least that I know of) finding out when a new version is
published in Cincom repository. so basically I would like to have
something like the Adept updater, checks in all repositories for new
versions of the packages loaded in my image and warns me when a new
version is available.

> I suggest you create a local repository to which your image connects  
> and use the replicator tools to ensure the latest versions of third-
> party packages are present in your local repository.

Mmm, I see, but I'm not quite sure how this would be automated for
many repositories. Could you give me a hint here?

> I find it helpful to load the replicator in a separate image - it is  
> not helpful if its life cycle is dictated by whatever you do to your  
> development image.

Nice, didn't think about that one!

 > Also make sure you use the Glorp based replicator,
> I understand the Store based one is suspect. (i.e. load parcel  
> StoreForGlorpvWUI)

Yes, I've just switched from the "standard" replicator to the Glorp-based

> Now that your development image needs to connect to only one  
> repository you can make use of the store tools like for instance the  
> menu command'More recently published items'. (We found it helpful to  
> add a menu item that does 'More recently published items with blessing  
>  >= development').

Yes, actually I've a script that on start up does exactly this.

> There is one gotcha with replication you need to be aware of:
> Prior to 7.6 store clients (the development images in our scenario)  
> would assume that higher database id's would imply younger time  
> stamps. This assumption breaks down when the repository contains  
> replicated code. See also pkg 'Store-Replication support patches' in  
> the public repository.

Ok, but this is fixed in glorp, right?

> See parcel StoreForGlorp :-)

Ok :)

Thanks for the detailed answer!
Andrés
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

>> I suggest you create a local repository to which your image connects  
>> and use the replicator tools to ensure the latest versions of third-
>> party packages are present in your local repository.
>>    
>
> Mmm, I see, but I'm not quite sure how this would be automated for
> many repositories. Could you give me a hint here?
>  

After loading StoreForGlorpVWUI you get an extra item 'Replication' in
the VW settings window.
Its child item is called 'Auto-Replication Rules',   press the 'help'
button there for details :-)




The bundle fixes it for Store without Glorp (which I guess is exactly
what you need when connecting older images to your new local repository
-- Glorp only being used by the replicator image).





Reinout
--------

--
*********************************************************************

Dit e-mailbericht is alleen bestemd voor de geadresseerde(n).

Gebruik door anderen is niet toegestaan. Indien u niet degeadresseerde(n) bent wordt u verzocht de verzender hiervan op de hoogte te stellen en het bericht te verwijderen. Door de elektronische verzending kunnen aan de inhoud van dit bericht geen rechten worden ontleend.

Soops B.V. is gevestigd te Amsterdam, Nederland, en is geregistreerd bij de Kamer van Koophandel onder nummer 33240368.
Soops B.V. levert volgens de Fenit voorwaarden, gedeponeerd te Den Haag op 8 december 1994 onder nummer 1994/189.
**********************************************************************

This e-mail message is intended to be exclusively for the addressee.

If you are not the intended recipient you are kindly requested not to make any use whatsoever of the contents and to notify the sender immediately by returning this e-mail message. No rights can be derived from this message.

Soops B.V. is a private limited liability company and has its seat at Amsterdam, The Netherlands and is registered with the Trade Registry of the Chamber of Commerce and Industry under number 33240368.
Soops B.V. delivers according to the General Terms and Conditions of Business of Fenit, registered at The Hague, The Netherlands on December 8th, 1994, under number 1994/189
**********************************************************************



_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc