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-28-2008, 10:37 PM
James Vega
 
Default RFC: Idea for improved diversions and alternatives handling

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
> ".diverted" by default, since we wouldn't want diversions from multiple
> packages to collide. Maybe ".diverted-$package", then?

I don't think this scenario makes sense outside of transitioning a
diversion from one package to another.

There are two use cases to consider regarding multiple packages and
diversions.

1) Multiple packages installing a file that has been diverted.
Currently, there is only one "divert to" filename so you'll end up
losing data once the second diverted file is installed. This could be
alleviated by instead basing the "divert to" filename on the package
which contains the file being diverted (as you suggest above).

There's still the problem of what to do when the package providing the
diversion is uninstalled as now you have conflicting packages.
Actually, you already had conflicting packages that just weren't
affected yet because of the diversion, which leads to 2).

2) Multiple packages diverting the same file.
This currently isn't possible since dpkg-divert will rightly complain
about multiple packages trying to divert the same file. If it were to
be possible, you would need a layered approach with priorities so
there's a defined notion of which package is currently providing the
contested file and who would do so when that package is removed. In
this case, congratulations, you've reinvented alternatives.

So it seems like the solution to both of the above scenarios is the use
of alternatives. There is the problem which brian brought up[0] about
using diversions when you can't rely on having alternatives setup
already but that would be obviated if dpkg internally handled both
diversions and alternatives.

[0] - 20080627172930.GB7523@crustytoothpaste.ath.cx
--
James
GPG Key: 1024D/61326D40 2003-09-02 James Vega <jamessan@debian.org>
 
Old 07-01-2008, 04:44 PM
Goswin von Brederlow
 
Default RFC: Idea for improved diversions and alternatives handling

James Vega <jamessan@debian.org> 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 target - or at least for not using
>> ".diverted" by default, since we wouldn't want diversions from multiple
>> packages to collide. Maybe ".diverted-$package", then?
>
> I don't think this scenario makes sense outside of transitioning a
> diversion from one package to another.
>
> There are two use cases to consider regarding multiple packages and
> diversions.
>
> 1) Multiple packages installing a file that has been diverted.
> Currently, there is only one "divert to" filename so you'll end up
> losing data once the second diverted file is installed. This could be
> alleviated by instead basing the "divert to" filename on the package
> which contains the file being diverted (as you suggest above).
>
> There's still the problem of what to do when the package providing the
> diversion is uninstalled as now you have conflicting packages.
> Actually, you already had conflicting packages that just weren't
> affected yet because of the diversion, which leads to 2).

It is not allowed for two packages to contain the same file without a
diversion. I see no reason to suddnely allow it if a 3rd pckage
diverts the file. dpkg should just complain that the file already
exists.

> 2) Multiple packages diverting the same file.
> This currently isn't possible since dpkg-divert will rightly complain
> about multiple packages trying to divert the same file. If it were to
> be possible, you would need a layered approach with priorities so
> there's a defined notion of which package is currently providing the
> contested file and who would do so when that package is removed. In
> this case, congratulations, you've reinvented alternatives.

I think this should really be limited to transitioning a diversion
from A to B. As such dpkg should recognise that A looses the diversion
and B gains it and only change the owner of the diversion in its
database. Nothing else changes. This would require that both A and B
are updated as pair but that is nothing new.

MfG
Goswin


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 07-01-2008, 04:44 PM
Goswin von Brederlow
 
Default RFC: Idea for improved diversions and alternatives handling

James Vega <jamessan@debian.org> 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 target - or at least for not using
>> ".diverted" by default, since we wouldn't want diversions from multiple
>> packages to collide. Maybe ".diverted-$package", then?
>
> I don't think this scenario makes sense outside of transitioning a
> diversion from one package to another.
>
> There are two use cases to consider regarding multiple packages and
> diversions.
>
> 1) Multiple packages installing a file that has been diverted.
> Currently, there is only one "divert to" filename so you'll end up
> losing data once the second diverted file is installed. This could be
> alleviated by instead basing the "divert to" filename on the package
> which contains the file being diverted (as you suggest above).
>
> There's still the problem of what to do when the package providing the
> diversion is uninstalled as now you have conflicting packages.
> Actually, you already had conflicting packages that just weren't
> affected yet because of the diversion, which leads to 2).

It is not allowed for two packages to contain the same file without a
diversion. I see no reason to suddnely allow it if a 3rd pckage
diverts the file. dpkg should just complain that the file already
exists.

> 2) Multiple packages diverting the same file.
> This currently isn't possible since dpkg-divert will rightly complain
> about multiple packages trying to divert the same file. If it were to
> be possible, you would need a layered approach with priorities so
> there's a defined notion of which package is currently providing the
> contested file and who would do so when that package is removed. In
> this case, congratulations, you've reinvented alternatives.

I think this should really be limited to transitioning a diversion
from A to B. As such dpkg should recognise that A looses the diversion
and B gains it and only change the owner of the diversion in its
database. Nothing else changes. This would require that both A and B
are updated as pair but that is nothing new.

MfG
Goswin


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

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 or alternatives behind. Instead I suggest creating two new
> control files detailing the diversions and alternatives a package
> should have.

Can symlinks be supported in the declarative control file stanzas?

One problem within Emdebian is replacing coreutils etc. with busybox -
currently we are having to use a rigid replacement where the options
enabled in busybox must be removed from the package set (or added as
Conflicts: in busybox) and then the symlinks for each applet are listed
in the dpkg file list. This requires a particular level of coordination
and makes it harder to customise Emdebian for a different scenario.

If both /bin/foo and /bin/bar are called during the boot/init process,
the issue is allowing for this scenario:

Install package foo, includes symlink /bin/bar -> /bin/foo
Also includes a variety of others (about 30 in total).

At a later date, the installation needs to be customised to allow the
"full" version of /bin/bar from package bar to be installed for extra
functionality. If Replaces: is used, bar cannot be removed because the
box would not be bootable anymore - the previous symlink has gone
forever.

How to divert a symlink such that it can be restored later?

Alternatives isn't a good solution because it means reimplementing the
alternatives support code to avoid the use of Perl - and alternatives
(IIRC) does not support symlinks as alternatives.

What I need to avoid is having to make dozens of changes to postinst
scripts to enable diversions in a long list of packages.

Busybox 1.10.3 (not yet in Debian) does support discrete binaries linked
to a shared library version of busybox but the library is bigger than
the current busybox binary and each discrete binary is just over 4Kb so
that is an appreciable increase in total size. (Seeing as this is
busybox, size increases must be avoided.) It would allow the use of
alternatives (subject to replacement non-perl code) but that method also
needs changes in other packages (currently). So that costs an extra 2Mb
or so and involves rewriting the code supporting alternatives - not my
favourite option when the entire OS has to fit into 32Mb (or 64Mb for a
full GUI using glibc).

--


Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/
 
Old 07-06-2008, 04:30 PM
Neil Williams
 
Default RFC: Idea for improved diversions and alternatives handling

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 or alternatives behind. Instead I suggest creating two new
> control files detailing the diversions and alternatives a package
> should have.

Can symlinks be supported in the declarative control file stanzas?

One problem within Emdebian is replacing coreutils etc. with busybox -
currently we are having to use a rigid replacement where the options
enabled in busybox must be removed from the package set (or added as
Conflicts: in busybox) and then the symlinks for each applet are listed
in the dpkg file list. This requires a particular level of coordination
and makes it harder to customise Emdebian for a different scenario.

If both /bin/foo and /bin/bar are called during the boot/init process,
the issue is allowing for this scenario:

Install package foo, includes symlink /bin/bar -> /bin/foo
Also includes a variety of others (about 30 in total).

At a later date, the installation needs to be customised to allow the
"full" version of /bin/bar from package bar to be installed for extra
functionality. If Replaces: is used, bar cannot be removed because the
box would not be bootable anymore - the previous symlink has gone
forever.

How to divert a symlink such that it can be restored later?

Alternatives isn't a good solution because it means reimplementing the
alternatives support code to avoid the use of Perl - and alternatives
(IIRC) does not support symlinks as alternatives.

What I need to avoid is having to make dozens of changes to postinst
scripts to enable diversions in a long list of packages.

Busybox 1.10.3 (not yet in Debian) does support discrete binaries linked
to a shared library version of busybox but the library is bigger than
the current busybox binary and each discrete binary is just over 4Kb so
that is an appreciable increase in total size. (Seeing as this is
busybox, size increases must be avoided.) It would allow the use of
alternatives (subject to replacement non-perl code) but that method also
needs changes in other packages (currently). So that costs an extra 2Mb
or so and involves rewriting the code supporting alternatives - not my
favourite option when the entire OS has to fit into 32Mb (or 64Mb for a
full GUI using glibc).

--


Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/
 
Old 07-10-2008, 09:22 AM
Goswin von Brederlow
 
Default RFC: Idea for improved diversions and alternatives handling

Neil Williams <codehelp@debian.org> 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 prone to errors and can easily leave
>> diversions or alternatives behind. Instead I suggest creating two new
>> control files detailing the diversions and alternatives a package
>> should have.
>
> Can symlinks be supported in the declarative control file stanzas?

Don't symlinks work in diversions now?

Diverting should just move the file around so I see no reason why it
should even care about the file type.

MfG
Goswin


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 07-10-2008, 09:22 AM
Goswin von Brederlow
 
Default RFC: Idea for improved diversions and alternatives handling

Neil Williams <codehelp@debian.org> 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 prone to errors and can easily leave
>> diversions or alternatives behind. Instead I suggest creating two new
>> control files detailing the diversions and alternatives a package
>> should have.
>
> Can symlinks be supported in the declarative control file stanzas?

Don't symlinks work in diversions now?

Diverting should just move the file around so I see no reason why it
should even care about the file type.

MfG
Goswin


--
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 11:02 AM.

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