Re: [gentoo-dev] RFC: new feature to disable merging into stray locations
On Mon, Apr 30, 2012 at 03:36:17PM +0200, Ulrich Mueller wrote:
> > On Mon, 30 Apr 2012, Thomas Sachau wrote:
>
> > Krzysztof Pawlik schrieb:
> >> On 30/04/12 10:39, Ulrich Mueller wrote:
> > If the eclass doesn't work with FEATURES="collision-protect"
> > then it needs to be fixed.
> >>>
> Long story short: older eclass compiled Python byte code in live
> file system, new one does it in src_install so .pyo/.pyc gets
> properly recorded, so the package *has to overwrite* files that
> are not owned by anyone (no package owns them).
> >>>
> >>> The usual approach to this problem was to have some cleanup code
> >>> in pkg_setup or pkg_preinst that would remove the old files.
> >>
> >> Interesting idea - I see two problems:
> >> - how I would get the list of files for already installed version
> >> (the file list can (and will) differ between versions)
>
> > Simple workaround in pkg_preinst (just example code, nothing to
> > copy/paste):
>
> > if has_version < first_good_version ; then
> > for i in $(find ${D} -name *.{pyc,pyo}) ; do
> > [[ -e ${i/${D}/${ROOT}/} ]] && rm ${i/${D}/${ROOT}/}
> > done
> > fi
>
> This wouldn't work, because collision protection runs _before_
> pkg_preinst.
>
> However, one could imagine a (somewhat dirty) workaround:
> - At the end of src_install, rename all *.pyc and *.pyo in ${D} to
> names that don't collide with the ones in ${ROOT}, so that collision
> protection won't be triggered.
> - At the beginning of pkg_preinst, rename them back to their original
> names.
> - Run above code.
>
> > Alternatively, you could take all .py files of the installed
> > versions and blindly remove the pyo/pyc files for them in
> > pkg_preinst (this should also prevent leaving dead files around).
>
> s/preinst/setup/ otherwise the same argument as above would apply.
The checks above can misbehave.
Pretty sure I've already suggested this route for this specific issue,
but QA vars in the ebuild that portage can use for hints is a sane,
non-cluster-fucky way to deal with this. Something along the lines of
QA_COLLISION_PROTECT_IGNORE='*.pyc'
Still has the potential for things going boom, but warnings can be
setup for when collision-protect is on, and the portage version
doesn't look new enough (those being details; point is the general
approach).
~harring
Re: [gentoo-dev] busybox[sep-usr] support for mounting /usr w/out hassle
On Mon, Apr 30, 2012 at 11:59:02AM -0400, Mike Frysinger wrote: > the fact that the script leaves your system in a hard to recover state is > what > i'm whining about, not that udev requires devtmpfs. So why did you decide to whine instead of opening a bug? :p > /dev/pts isn't created, thus devpts doesn't get mounted, thus you cannot log > in to your system to fix it. would also be trivial to run the all of three > commands so people could recover: > mount -t tmpfs dev /dev > busybox mdev -s > mkdir /dev/pts Yes, I could do this. > we already have examples of the init scripts modifying /etc/issue to notify > login entry points that their system needs manual attention to recover. This part can't happen in the udev init script since / is ro when it is run. Doing something in udev-postmount is also eroneous because that assumes that the user is booting to the default runlevel which they may not be. The best thing I can think of to do is to just log a message about it in udev-mount and fail which will cause udev to fail. William pgpyzoloSPqGp.pgp Description: PGP signature
Re: [gentoo-dev] busybox[sep-usr] support for mounting /usr w/out hassle
On Tuesday 01 May 2012 11:06:42 William Hubbs wrote: > On Mon, Apr 30, 2012 at 11:59:02AM -0400, Mike Frysinger wrote: > > the fact that the script leaves your system in a hard to recover state is > > what i'm whining about, not that udev requires devtmpfs. > > So why did you decide to whine instead of opening a bug? :p based on past behavior, i assumed it was operating as indented > > we already have examples of the init scripts modifying /etc/issue to > > notify login entry points that their system needs manual attention to > > recover. > > This part can't happen in the udev init script since / is ro when it is > run. Doing something in udev-postmount is also eroneous because that > assumes that the user is booting to the default runlevel which they may > not be. in the past, we would `mount -o remount,rw /`, but that was because we needed to add missing dirs in /. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] busybox[sep-usr] support for mounting /usr w/out hassle
On Tuesday 01 May 2012 11:45:01 Mike Frysinger wrote: > On Tuesday 01 May 2012 11:06:42 William Hubbs wrote: > > On Mon, Apr 30, 2012 at 11:59:02AM -0400, Mike Frysinger wrote: > > > the fact that the script leaves your system in a hard to recover state > > > is what i'm whining about, not that udev requires devtmpfs. > > > > So why did you decide to whine instead of opening a bug? :p > > based on past behavior, i assumed it was operating as indented blah, swap that 't' & 'd' -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] busybox[sep-usr] support for mounting /usr w/out hassle
On Tue, May 01, 2012 at 11:45:01AM -0400, Mike Frysinger wrote: > On Tuesday 01 May 2012 11:06:42 William Hubbs wrote: > > On Mon, Apr 30, 2012 at 11:59:02AM -0400, Mike Frysinger wrote: > > > the fact that the script leaves your system in a hard to recover state is > > > what i'm whining about, not that udev requires devtmpfs. > > > > So why did you decide to whine instead of opening a bug? :p > > based on past behavior, i assumed it was operating as indented > > > > we already have examples of the init scripts modifying /etc/issue to > > > notify login entry points that their system needs manual attention to > > > recover. > > > > This part can't happen in the udev init script since / is ro when it is > > run. Doing something in udev-postmount is also eroneous because that > > assumes that the user is booting to the default runlevel which they may > > not be. > > in the past, we would `mount -o remount,rw /`, but that was because we needed > to add missing dirs in /. Hmm, if I do that I would also have to put it back ro after I modify issue because fsck hasn't run yet... Do we want to mess around with the fs before fsck is run? William pgpywRiUs1cB0.pgp Description: PGP signature
[gentoo-dev] Re: busybox[sep-usr] support for mounting /usr w/out hassle
Mike Frysinger posted on Tue, 01 May 2012 12:13:27 -0400 as excerpted: > On Tuesday 01 May 2012 11:45:01 Mike Frysinger wrote: >> based on past behavior, i assumed it was operating as indented > > blah, swap that 't' & 'd' I thought for SURE that was a deliberate play on words. Mind if I borrow the phrase? "Operating as indented!" Indeed! Sounds like a bit too much "percussive maintenance"! -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
Re: [gentoo-dev] busybox[sep-usr] support for mounting /usr w/out hassle
On Tuesday 01 May 2012 12:51:55 William Hubbs wrote: > On Tue, May 01, 2012 at 11:45:01AM -0400, Mike Frysinger wrote: > > On Tuesday 01 May 2012 11:06:42 William Hubbs wrote: > > > On Mon, Apr 30, 2012 at 11:59:02AM -0400, Mike Frysinger wrote: > > > > we already have examples of the init scripts modifying /etc/issue to > > > > notify login entry points that their system needs manual attention to > > > > recover. > > > > > > This part can't happen in the udev init script since / is ro when it is > > > run. Doing something in udev-postmount is also eroneous because that > > > assumes that the user is booting to the default runlevel which they may > > > not be. > > > > in the past, we would `mount -o remount,rw /`, but that was because we > > needed to add missing dirs in /. > > Hmm, if I do that I would also have to put it back ro after I modify > issue because fsck hasn't run yet... > > Do we want to mess around with the fs before fsck is run? the previous cases made sense in context (they had to modify / anyways), so if you wanted to skip that step, it's probably fine. i'm not too worried about fsck as many nowadays recover their journal gracefully at mount time ... -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] busybox[sep-usr] support for mounting /usr w/out hassle
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/05/12 09:51, William Hubbs wrote: > Hmm, if I do that I would also have to put it back ro after I modify > issue because fsck hasn't run yet... > > Do we want to mess around with the fs before fsck is run? We could play it safe and store the messages somewhere in tmpfs and write them to issue right before giving a shell. lu - -- Luca Barbato Gentoo/linux http://dev.gentoo.org/~lu_zero -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+gvZMACgkQ6Ex4woTpDjQeZwCeMfp6r41zDcTGcOpfeJDQEjlF GIsAoNVx0cGwV7jcVJA6N6DpIbDeXxRk =UvEC -END PGP SIGNATURE-
