FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian dpkg

 
 
LinkBack Thread Tools
 
Old 06-27-2008, 06:40 AM
Tollef Fog Heen
 
Default RFC: Idea for improved diversions and alternatives handling

* 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 with a bit of
thought and great care, it is sometimes necessary. In that case, making
sure the diverted library goes to a separate directory often makes sense
to avoid confusing ldconfig. Therefore, I would like to be able to
specify the path to be diverted to, not just the pathname to be
diverted. I guess we could make it optional, so the common case would
just be:

debian/foo.divert:
/bin/ls

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'm not completely sure about, but it probably makes sense
for it to be dpkg, making sure it's root:root 0644).

--
Tollef Fog Heen / Linpro AS t: 21 54 41 73

UNIX is user friendly, it's just picky about who its friends are


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 06-27-2008, 07:18 AM
Stefano Zacchiroli
 
Default RFC: Idea for improved diversions and alternatives handling

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 something like .dpkg-diverted would be more
consistent with other files explicitly renamed by dpkg in various
occasions (mainly conffile handling) though.

> While diverting libraries is something that should be done with a bit of
> thought and great care, it is sometimes necessary. In that case, making
> sure the diverted library goes to a separate directory often makes sense
> to avoid confusing ldconfig. Therefore, I would like to be able to

Point, but wouldn't it be better to hack ldconfig to ignore
*.dpkg-diverted (or whatever naming convention we choose of course)
while scanning lib dirs? I understand that ldconfig is kind of delicate,
but the modification is in theory simple and will avoid complicating the
declarative diversion specification.

Cheers.

--
Stefano Zacchiroli -*- PhD in Computer Science PostDoc @ Univ. Paris 7
zack@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
I'm still an SGML person,this newfangled / All one has to do is hit the
XML stuff is so ... simplistic -- Manoj / right keys at the right time
 
Old 06-27-2008, 04:40 PM
Mike Hommey
 
Default RFC: Idea for improved diversions and alternatives handling

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 upgrade without rm'ing one's own package files
> > in the prerm in order to handle diversion changes, and that's just nasty.
> > I'm happy to see people thinking about this.
>
> Absolutely. I would agree with Steve Langasek's comments, though.
>
> 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 diversions file would be better.
>
> Looking at the options to dpkg-divert:
>
> --add --remove --package
> Should be inferred by dpkg and not specifiable in diversions
> --divert
> In practice diversity in this option seems to cause more
> trouble than it's worse. Perhaps we should settle on
> `.diverted' or something ?

What should happen when several packages divert the same file ?
Which one wins ? What about original files, what do they become ?

Mike


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 06-27-2008, 04:40 PM
Mike Hommey
 
Default RFC: Idea for improved diversions and alternatives handling

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 upgrade without rm'ing one's own package files
> > in the prerm in order to handle diversion changes, and that's just nasty.
> > I'm happy to see people thinking about this.
>
> Absolutely. I would agree with Steve Langasek's comments, though.
>
> 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 diversions file would be better.
>
> Looking at the options to dpkg-divert:
>
> --add --remove --package
> Should be inferred by dpkg and not specifiable in diversions
> --divert
> In practice diversity in this option seems to cause more
> trouble than it's worse. Perhaps we should settle on
> `.diverted' or something ?

What should happen when several packages divert the same file ?
Which one wins ? What about original files, what do they become ?

Mike


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 06-27-2008, 04:58 PM
James Vega
 
Default 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 files, what do they become ?

Several packages shouldn't divert the same file, IMO. diversions
are useful for specific circumstances and the diverted/diverting
packages should be closely related (if not from the source).
Alternatives are the better solution when there are myriad,
non-conflicting sources which may provide the same file.

--
James
GPG Key: 1024D/61326D40 2003-09-02 James Vega <jamessan@debian.org>
 
Old 06-27-2008, 04:58 PM
James Vega
 
Default 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 files, what do they become ?

Several packages shouldn't divert the same file, IMO. diversions
are useful for specific circumstances and the diverted/diverting
packages should be closely related (if not from the source).
Alternatives are the better solution when there are myriad,
non-conflicting sources which may provide the same file.

--
James
GPG Key: 1024D/61326D40 2003-09-02 James Vega <jamessan@debian.org>
 
Old 06-27-2008, 05:29 PM
"brian m. carlson"
 
Default RFC: Idea for improved diversions and alternatives handling

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 file, IMO. diversions
are useful for specific circumstances and the diverted/diverting
packages should be closely related (if not from the source).
Alternatives are the better solution when there are myriad,
non-conflicting sources which may provide the same file.


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 alternatives mechanism to be set up. And the only
other option I see (other than diversions) is to prohibit changing
/bin/sh, which will make a lot of people very upset.

I agree that alternatives are the optimal tool here, but I don't know
how that can be achieved. Suggestions welcome.

--
brian m. carlson / brian with sandals: Houston, Texas, US
+1 713 440 7475 | http://crustytoothpaste.ath.cx/~bmc | My opinion only
troff on top of XML: http://crustytoothpaste.ath.cx/~bmc/code/thwack
OpenPGP: RSA v4 4096b 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187
 
Old 06-27-2008, 05:29 PM
"brian m. carlson"
 
Default RFC: Idea for improved diversions and alternatives handling

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 file, IMO. diversions
are useful for specific circumstances and the diverted/diverting
packages should be closely related (if not from the source).
Alternatives are the better solution when there are myriad,
non-conflicting sources which may provide the same file.


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 alternatives mechanism to be set up. And the only
other option I see (other than diversions) is to prohibit changing
/bin/sh, which will make a lot of people very upset.

I agree that alternatives are the optimal tool here, but I don't know
how that can be achieved. Suggestions welcome.

--
brian m. carlson / brian with sandals: Houston, Texas, US
+1 713 440 7475 | http://crustytoothpaste.ath.cx/~bmc | My opinion only
troff on top of XML: http://crustytoothpaste.ath.cx/~bmc/code/thwack
OpenPGP: RSA v4 4096b 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187
 
Old 06-27-2008, 06:34 PM
Ian Jackson
 
Default RFC: Idea for improved diversions and alternatives handling

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 files, what do they become ?
>
> Several packages shouldn't divert the same file, IMO. diversions
> are useful for specific circumstances and the diverted/diverting
> packages should be closely related (if not from the source).
> Alternatives are the better solution when there are myriad,
> non-conflicting sources which may provide the same file.

That's all very well but what about transitions ?
For example:

old A diverts and contains /usr/bin/p /usr/bin/p
new A does nothing with /usr/bin/p
old B does nothing with /usr/bin/p
new B replaces old A, diverts and contains /usr/bin/p

Do we regard B's replacement of A to mean that B's diversion of A
should be compatible with A's ? etc.

This all needs some careful thought I think, to make sure we get all
of the corner cases right.

Ian.


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 06-27-2008, 06:34 PM
Ian Jackson
 
Default RFC: Idea for improved diversions and alternatives handling

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 files, what do they become ?
>
> Several packages shouldn't divert the same file, IMO. diversions
> are useful for specific circumstances and the diverted/diverting
> packages should be closely related (if not from the source).
> Alternatives are the better solution when there are myriad,
> non-conflicting sources which may provide the same file.

That's all very well but what about transitions ?
For example:

old A diverts and contains /usr/bin/p /usr/bin/p
new A does nothing with /usr/bin/p
old B does nothing with /usr/bin/p
new B replaces old A, diverts and contains /usr/bin/p

Do we regard B's replacement of A to mean that B's diversion of A
should be compatible with A's ? etc.

This all needs some careful thought I think, to make sure we get all
of the corner cases right.

Ian.


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 

Thread Tools




All times are GMT. The time now is 01:22 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org