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