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