Re: Linux image packages going to depend on python
On Sat, Nov 28 2009, Ben Hutchings wrote:
> On Sat, 2009-11-28 at 16:43 -0600, Manoj Srivastava wrote:
>> On Sat, Nov 28 2009, Neil Williams wrote:
>>
>> > On Sat, 28 Nov 2009 18:56:01 +0100
>> > Patrick Matthäi <pmatthaei@debian.org> wrote:
>> >
>> >> Am 28.11.2009 18:52, schrieb Bastian Blank:
>> >> > Hi folks
>> >> >
>> >> > The Linux image packages needs to do some modifications to core
>> >> > configuration files like fstab in the future to allow newer kernels to
>> >> > work. To do this and the planned further extension I intend to make all
>> >> > linux image packages depend on python.
>> >
>> > This sounds like a maintainer-script issue rather than a direct
>> > requirement of the image itself. Would it be possible for the scripts
>> > to check for python support and continue *without error* if python is
>> > not found? This way, systems that do not have python but *do* have a
>> > setup capable of implementing whatever changes are suitable can still
>> > use a vanilla Debian kernel, e.g. during debugging.
>> >
>> > Note 'suitable' - no matter what the kernel does or thinks it needs, it
>> > is not necessarily suitable for the maintainer scripts to fiddle with
>> > system config files on every system.
>>
>> Indeed. Editing configuration files that belong to other
>> packages is a policy violation; and even editing configuration files
>> blonging to he package itself must preserve all user changes.
>>
>> It seems to be that a better approach is to inform the user, and
>> let the admin make the changes needed.
>
> The specific requirement here is to prepare for a transition from old
> PATA ("IDE") drivers to libata-based drivers. libata presents ATA/ATAPI
> drives as SCSI devices, so hard drive partitions will change
> from /dev/hdX to /dev/sdX.
This is fine. /etc/fstab is used by mountall.sh, mount, and
swapon explicitly -- so arguably mount is the related package that
"owns" the configuration file. Here is what policy has to say about it:
,----[ 10.7.4. Sharing configuration files ]
| If two or more packages use the same configuration file and it is
| reasonable for both to be installed at the same time, one of these
| packages must be defined as _owner_ of the configuration file, i.e.,
| it will be the package which handles that file as a configuration
| file. Other packages that use the configuration file must depend on
| the owning package if they require the configuration file to operate.
| If the other package will use the configuration file if present, but
| is capable of operating without it, no dependency need be declared.
|
| If it is desirable for two or more related packages to share a
| configuration file _and_ for all of the related packages to be able to
| modify that configuration file, then the following should be done:
| 1. One of the related packages (the "owning" package) will manage
| the configuration file with maintainer scripts as described in
| the previous section.
| 2. The owning package should also provide a program that the other
| packages may use to modify the configuration file.
| 3. The related packages must use the provided program to make any
| desired modifications to the configuration file. They should
| either depend on the core package to guarantee that the
| configuration modifier program is available or accept gracefully
| that they cannot modify the configuration file if it is not.
| (This is in addition to the fact that the configuration file may
| not even be present in the latter scenario.)
|
| Sometimes it's appropriate to create a new package which provides the
| basic infrastructure for the other packages and which manages the
| shared configuration files. (The `sgml-base' package is a good
| example.)
`----
> In preparation for this partition, /etc/fstab and the kernel parameters
> in boot-loader configs should be changed to specify partitions by UUID
> or label name so that they work with both old and new kernel versions.
> There will be a debconf question as to whether this should be done
> automatically, but it is not appropriate to expect all users to make
> this change manually.
While it is not appropriate for the user to do it manually,
there is still a policy compliant way to do what is needed:
A) Have mount provide the use-uuids-in-fstab script, and have ask the
user if one may call it. If so, call it in the postinst
B) Detect if the fstab changes have happened, and if not, take
appropriate action.
Also, as a project, we still support user created kernel images;
and it is being nice to such users that the tools to automate the
fstab conversion for newer kernels; and not leave them out in the
cold.
Once the mount package provides the modify fstab script, users
can update their fstab ahead of time; and this can be detected in the
image postinst (on in the update fstab script) , and no special action
needs be taken.
This also means that the postinst does not get bloated with more
one-time use code.
manoj
--
Death didn't answer. He was looking at Spold in the same way as a dog
looks ata bone, only in this case things were more or less the other way
around. -- Terry Pratchett
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Reply to: