tech-pkg archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: First pkg_dry milestone

On Tue, Apr 14, 2009 at 04:21:41PM +0200, iMil wrote:
> Hi Thomas,
>> I have a set of binary packages installed. I want to install a new
>> (previously not installed) package, let's call it foo, without
>> disturbing my installation. foo depends on bar. bar-1.0 with
>> is installed. The latest version of bar in pkgsrc is
>> bar-2.0 with
>> The server has binary packages for foo-4.0 (built against bar-1.0) and
>> foo-4.0nb1 (built against bar-2.0).
>> pkg_dry -i should install foo-4.0, even though it's not the absolutely
>> latest version, but it works with the bar-1.0 that's installed.
>> AFAIK, the pkg_summary file contains sufficient information for this
>> case.
>> Alternatively, pkg_dry would have update bar and all its dependencies
>> to 2.0 first.
> Here's the way it works as of today :
> Assuming you want to install the package "foo", pkg_dry -i foo will query 
> the database (previously fed by pkg_summary(5)) for a PKGPATH of this  
> form: '*/foo-[0-9]*'. The package name is then given by PKGNAME. This  
> exact name, followed by the ".tgz" extension, is the name of the archive  
> to be dowloaded in ${PKG_PATH}.

That just selects the name, not the version to download.

> If foo has a dependency on bar>=1, there will be no more actions than the 
> download and installation of foo-X.Y.Z.tgz, the one mentionned in 

That's clear.

> If foo has a dependency on bar>=2, things are getting complicated. IMHO  
> there's two options here :
> . There's no more bar-1. in the repository, and as a matter of fact, no
>   more packages depending on bar-1, which means every package installed on
>   your system has now an upgrade in the repository with a new dependency
>   on bar-2
> . There's still a bar-1 living on the repository, usually in this kind of
>   situation we have bar1-[0-9]* and bar2-[0-9]*, but there's maybe a
>   counter-example.
> Do you have a real-life example of this kind of usecase ?

It's easier than your case.
Just take what I wrote above: You run one bulk build and upload it.
Then bar is bumped to 2.0 with a new shlib major, and a recursive
PKGREVISION++ for all dependencies. Bulk build, upload.

The server now has foo-4.0 built against and foo-4.0nb1
built against

This information is in the PKG_SUMMARY file:

It could be used to download the version that doesn't incur an update
of other packages.

Just an idea though, it's ok if you put it in a second step.


Home | Main Index | Thread Index | Old Index