tech-pkg archive

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

Re: Updating both Perl and Perl Modules from a binary repository



On Thu, Apr 19, 2012 at 08:12:13PM +0000, David Holland wrote:
> On Thu, Apr 19, 2012 at 10:03:35PM +0200, Joerg Sonnenberger wrote:
>  > On Thu, Apr 19, 2012 at 07:51:41PM +0000, David Holland wrote:
>  > > On Thu, Apr 19, 2012 at 03:33:41PM +0200, Edgar Fu? wrote:
>  > >  > > What does "pkg_add -u perl p5-Foo p5-Bar" say?
>  > >  >
>  > >  > I don't remember exactly, but in essence "this doesn't work".
>  > >  >
>  > >  > I think, it was that it couldn't install perl-5.14 because p5-*
>  > >  > depended on perl<5.14. And it couldn't update p5-Foo because that
>  > >  > would imply updating perl from 5.12 to 5.14, whereas p5-Bar
>  > >  > depended on perl<5.14.
>  > >  >
>  > >  > My impression was that pkg_add failed to realise that if if would
>  > >  > do *all* the updates at once, the result would be consistent, but
>  > >  > bailed out because there was no path of *gradually* performing the
>  > >  > updates that would, in each step, keep the dependencies fulfilled.
>  > > 
>  > > That would be a bug.
>  > 
>  > I would disagree. The core issue here is that you can't do this update
>  > with "local" changes. To keep the set of installed packages consistent,
>  > you have to remove all Perl packages, update Perl and re-install them.
>  > This case (having to deinstall something else first) is exactly what IMO
>  > should *not* be the task of pkg_add, but a higher level tool. The
>  > existing logic to recursively update dependencies is already borderline,
>  > but forcing logic for even more complicated cases is not useful.
> 
> Nearly every successful binary package system I can think of supports
> transactional updates of groups of packages at this level, to handle
> precisely this problem.

Depends on what you look at. dpkg for example is pretty dumb, even more
than pkg_install.

Joerg


Home | Main Index | Thread Index | Old Index