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
>> libbar.so.1 is installed. The latest version of bar in pkgsrc is
>> bar-2.0 with libbar.so.2.
>>
>> 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 
> PKGNAME.

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 libbar.so.1 and foo-4.0nb1
built against libbar.so.2.

This information is in the PKG_SUMMARY file:
REQUIRES=/usr/pkg/lib/libbar.so.1

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.

Cheers,
 Thomas


Home | Main Index | Thread Index | Old Index