Neil Williams <[EMAIL PROTECTED]> writes:
> Goswin von Brederlow wrote:
>> working on dpkg reminded me that I wanted to propose a better
>> diversion and alternatives handling for debian packages. Currently
>> they have to be manually added and removed in the maintainer
>> scripts. This method is
Goswin von Brederlow wrote:
> working on dpkg reminded me that I wanted to propose a better
> diversion and alternatives handling for debian packages. Currently
> they have to be manually added and removed in the maintainer
> scripts. This method is prone to errors and can easily leave
> diversions
James Vega <[EMAIL PROTECTED]> writes:
> On Sat, Jun 28, 2008 at 02:03:05AM -0700, Steve Langasek wrote:
>> So if we allow multiple packages to be installed at the same time which
>> divert the same file, then I think we have another case for wanting to
>> continue supporting an optional diversion
On Sat, Jun 28, 2008 at 02:03:05AM -0700, Steve Langasek wrote:
> So if we allow multiple packages to be installed at the same time which
> divert the same file, then I think we have another case for wanting to
> continue supporting an optional diversion target - or at least for not using
> ".diver
On Thu, Jun 26, 2008 at 10:05:53PM +0100, Ian Jackson wrote:
> I don't think replicating the options to dpkg-divert in the diversions
> file is the correct approach. The implementation won't be done by
> having dpkg call dpkg-divert (I hope!) and I think a less arbitrary
> set of syntaxes for the
On Fri, Jun 27, 2008 at 07:56:41PM +0100, Ian Jackson wrote:
brian m. carlson writes ("Re: RFC: Idea for improved diversions and alternatives
handling"):
You still have to handle multiple diversions for /bin/sh. When d-i
installs the system, you have to have a working /bin/sh immedi
On Fri, Jun 27, 2008 at 07:34:53PM +0100, Ian Jackson wrote:
> James Vega writes ("Re: RFC: Idea for improved diversions and alternatives
> handling"):
> > On Fri, Jun 27, 2008 at 06:40:23PM +0200, Mike Hommey wrote:
> > > What should happen when severa
brian m. carlson writes ("Re: RFC: Idea for improved diversions and
alternatives handling"):
> You still have to handle multiple diversions for /bin/sh. When d-i
> installs the system, you have to have a working /bin/sh immediately; you
> can't wait for the alternative
Tollef Fog Heen writes ("Re: RFC: Idea for improved diversions and alternatives
handling"):
> And the uncommon case:
> debian/foo.divert:
> /lib/libc.so.6 /lib/foo/libc.so.6
>
> (Whose responsibility it is to ensure /lib/foo exists in that scenario
> is something I
James Vega writes ("Re: RFC: Idea for improved diversions and alternatives
handling"):
> On Fri, Jun 27, 2008 at 06:40:23PM +0200, Mike Hommey wrote:
> > What should happen when several packages divert the same file ?
> > Which one wins ? What about original f
On Fri, Jun 27, 2008 at 12:58:14PM -0400, James Vega wrote:
On Fri, Jun 27, 2008 at 06:40:23PM +0200, Mike Hommey wrote:
What should happen when several packages divert the same file ?
Which one wins ? What about original files, what do they become ?
Several packages shouldn't divert the same
On Fri, Jun 27, 2008 at 06:40:23PM +0200, Mike Hommey wrote:
> What should happen when several packages divert the same file ?
> Which one wins ? What about original files, what do they become ?
Several packages shouldn't divert the same file, IMO. diversions
are useful for specific circumstances
On Thu, Jun 26, 2008 at 10:05:53PM +0100, Ian Jackson wrote:
> Steve Langasek writes ("Re: RFC: Idea for improved diversions and
> alternatives handling"):
> > Declarative diversions are a much-needed enhancement to dpkg; there are
> > cases one cannot deal with on
On Fri, Jun 27, 2008 at 08:40:35AM +0200, Tollef Fog Heen wrote:
> * Ian Jackson
> | --divert
> | In practice diversity in this option seems to cause more
> | trouble than it's worse. Perhaps we should settle on
> | `.diverted' or something ?
I like this idea. Going for somet
* Ian Jackson
| --divert
| In practice diversity in this option seems to cause more
| trouble than it's worse. Perhaps we should settle on
| `.diverted' or something ?
[...]
| Which leaves only the pathname :-).
While diverting libraries is something that should be done wi
Steve Langasek writes ("Re: RFC: Idea for improved diversions and alternatives
handling"):
> Declarative diversions are a much-needed enhancement to dpkg; there are
> cases one cannot deal with on upgrade without rm'ing one's own package files
> in the prerm in orde
Steve Langasek <[EMAIL PROTECTED]> writes:
> Er, I've for the life of me never understood why --rename is even an
> *option* to dpkg-divert. What does dpkg-divert do without it, and how is
> that useful?
Only thing I can think of is something like this:
dpkg-divert --package my-libc6-wrapper --
On Mon, Jun 23, 2008 at 12:49:08AM +0200, Goswin von Brederlow wrote:
> Steve Langasek <[EMAIL PROTECTED]> writes:
> >> FIXME: what if a line changes? Only allow certain changes?
> > ... that's a rather large FIXME. Without fixing this, such an
> > implementation of declarative diversions would
Steve Langasek <[EMAIL PROTECTED]> writes:
>> FIXME: what if a line changes? Only allow certain changes?
>
> ... that's a rather large FIXME. Without fixing this, such an
> implementation of declarative diversions would be pointless churn.
>
> You should perhaps discuss this with Ian Jackson, the
On Sun, Jun 22, 2008 at 07:05:29PM +0200, Goswin von Brederlow wrote:
> working on dpkg reminded me that I wanted to propose a better
> diversion and alternatives handling for debian packages. Currently
> they have to be manually added and removed in the maintainer
> scripts. This method is prone
20 matches
Mail list logo