Re: s,/sbin/update-grub,update-grub,g transition

2006-08-06 Thread Manoj Srivastava
On Sun, 6 Aug 2006 09:11:52 +0200, Robert Millan [EMAIL PROTECTED] said: 

 As for #361929, I overlooked that kernel-package also happens to be
 the most appropiate place for fixing the user scripts.  Would you
 please also add something like:

I reject this assertion. There is no way of knowing when the
 end user will not be subject to kernel images built with
 kernel-package  10.051 -- which, incidentally, means every sing
 official image at the moment.  So a relative path is a really bad
 idea. 

And there is no reason for update-grub to go right now to a
 relative path -- update-grub is unlikely to ever move again.

On the other hand, we do know, when the path for
 update-sbin moves -- that is, when the new version is
 installed. kernel-package will have to test the location to see which
 path is valid for the current machine.

So, since a relative path for the postinst hook script would
 break all current images, and just changing the absolute path would
 work for the foreseeable future, the best place for this change is in
 grub.

Post Etch, at some point, one could try relative paths. Unless
 you plan on moving update-grub _again_, there is no point doing it,
 though. 

 sed -i /etc/kernel-img.conf -e
 s,\(.*\)/sbin/update-grub$,\1update-grub,g
 
 for linux-image-* postinsts ?
 
 (or whatever the perl equivalent is)

 Do you think it could be put in kernel-package as well ?  We could
 handle the transition in grub, but then we'd have to work out when
 do our kernel postinsts support relative paths, and it's not trivial
 because of the way kernel-package is used to generate postinsts in
 other packages.

This is the wrong fix.

Indeed, expect a grave bug from me (for breaking unrelated
 packages) if anything puts this scheme in place, since it would break
 an image which otherwise works just fine. If you must edit
 configuration files in place, go from one absolute path to another
 absolute path, depending on the path of the binary shipped in grub.

manoj
-- 
You are sick, twisted and perverted.  I like that in a person.
Manoj Srivastava   [EMAIL PROTECTED]  http://www.debian.org/%7Esrivasta/
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: s,/sbin/update-grub,update-grub,g transition

2006-08-06 Thread Manoj Srivastava
Hi,

Some more thoughts.

/etc/kernel-img.conf is a shared configuration file -- any
 number of kernel image and mkvmlinux packages that use that file may
 be installed pr going to be installed on the machine. Not all
 supported packages are official packages either -- anyone may compile
 their own custom kernel.

Policy states that to modify shared configuration files one
 sets up a special owner package that creates update mechanisms that
 preserve user changes, and provides this mechanism for other
 packages.

So, what can be the owner of the configuration file
 /etc/kernel-img.conf? Certainly no kernel image package can be, since
 kernel image packages come and they go, but /etc/kernel-img.conf
 lives on.

Also, how does one know when the file contains user changes
 are not? On my machine, I hand edited in the postinst_hook line, so
 changing that line is indeed not preserving user changes.  You may
 cry that the user changes are wrong, and would  not work anymore, and
 I would concede the point -- and yet, that is what policy says.

It would be ironic if a change made to satisfy one part of
 policy ends up having to violate another part of policy.

Arguably, the right way to handle this transition is to
 provide a compatibility symlink until Etch +1, when the
 kernel-package with the old behaviour would belong to Oldstable. At
 which point, in Etch+1, one can do away with the transition symlink
 in /sbin/update-grub.

manoj
-- 
Dyslexia means never having to say that you're ysror.
Manoj Srivastava   [EMAIL PROTECTED]  http://www.debian.org/%7Esrivasta/
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]