[gentoo-dev] Re: udev <-> mdev
The 13/07/12, William Hubbs wrote: > What about using devtmpfs alone? It's quiet fine for very simple systems. -- Nicolas Sebrecht
[gentoo-dev] Re: udev <-> mdev
Michael Mol posted on Sun, 15 Jul 2012 20:57:28 -0400 as excerpted: > This is sounding closer and closer to an on-disk liveCD. It is, isn't it? But I'd want to keep it reasonably small, as I guess I'd be rebuilding the squashfs pretty much whenever I updated any package that it contained binaries from. Actually, I guess if I did squashfs, I could even mount it directly, avoiding the initr* entirely, tho in effect it'd be close. I could have the kernel call a shell script as init, then have it exec the real init (and thus openrc) after it did some initial setup and mounts, thus allowing the real init to inherit the same PID 1 it normally gets. (Some of that idea is triggered by Maxim K's post. Thanks to both of you.) Alternatively, I could reconfigure inittab to start my script first, then start openrc (consolidating the openrc sysinit, etc, entries). But that actually sounds more complex than simply running an initial script as init, and having it exec init. -- 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] Re: udev <-> mdev
Duncan wrote: > Alternatively, I could reconfigure inittab to start my script first .. > that actually sounds more complex Use init. It would be a sensitive script. If it fails the kernel is sad. //Peter
Re: [gentoo-dev] multiple package moves into one
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 15/07/12 06:16 PM, Zac Medico wrote: > On 07/15/2012 03:08 PM, Doug Goldstein wrote: >> Is it valid to do something like: >> >> move media-plugins/mytharchive media-plugins/mythplugins move >> media-plugins/mythbrowser media-plugins/mythplugins move >> media-plugins/mythgallery media-plugins/mythplugins move >> media-plugins/mythgame media-plugins/mythplugins move >> media-plugins/mythmovies media-plugins/mythplugins move >> media-plugins/mythnews media-plugins/mythplugins move >> media-plugins/mythweather media-plugins/mythplugins > > No, that's not really how it's intended to be used. You'll probably > have to put blockers in media-plugins/mythplugins to block all the > old packages that install the same files. Theoretically (i've done a quick test on this and it seems true) a single-"!" blocker is enough that one package will on upgrade replace all these others without user intervention being required (assuming these packages aren't in @world, of course), and it won't cause file collisions. Unrelatedly curious, why the package merge? -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iF4EAREIAAYFAlAEG+cACgkQ2ugaI38ACPCz0QEAiuBnHl3Va2cHzUnUPT4eHFei kJXPBEnrsMq7jLX2H8IA/20zKcaGh+SsyTzh0jMauiTeh7zF1+PwLpcgJSpH0YS+ =BLip -END PGP SIGNATURE-
Re: [gentoo-dev] Re: udev <-> mdev
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 15/07/12 09:00 PM, Maxim Kammerer wrote: > On Mon, Jul 16, 2012 at 3:30 AM, Duncan <1i5t5.dun...@cox.net> > wrote: >> Thinking in that direction does stimulate yet another idea, tho. >> What about a squashfs root? AFAIK squashfs is read-only at use >> time, thus enforcing actually mounting something else to write >> anything, eliminating many of the down sides of sticking with the >> initial ramfs root, but it would allow the same flexibility in >> terms of sticking whatever into it at create-time, while only >> taking the memory necessary for what's actually stuck in it at >> create-time. > > It is possible, see: > https://github.com/mkdesu/liberte/blob/master/src/root/initrd/init > https://github.com/mkdesu/liberte/blob/master/src/etc/fstab > > The setup above is somewhat different from what you have in mind > (SquashFS image is located on disk, and contains the complete live > filesystem, not just a skeleton), so mounting read-writable > branches can be deferred to the regular post-initramfs services > (such as localmount) — on the other hand, maybe you want to do the > same (mount branches read-only in initramfs, and remount them > read-write in an init.d service). > ...if going this route, why not simply not bother to pivot_root out of the initramfs at all? or pivot_root but only into a directory structure still sitting in the initramfs? As long as all non-root bits are in separate storage, you can mount 'em all in the appropriate place... -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iF4EAREIAAYFAlAEHNAACgkQ2ugaI38ACPCbBgD+MCInpuQXjir37zFTn3ebJe30 dEWqqxihYox1+XrR7JYA/26jjkglGXZzxP0Kq17xuyoDBD8qnymAsziieDsMCMvN =/C5P -END PGP SIGNATURE-
[gentoo-dev] Last rites: gnustep-libs/popplerkit and gnustep-apps/vindaloo
# Bernard Cafarelli (16 Jul 2012) # No upstream development since 2008 # Needs patching for poppler-0.20 # Fails to run with current GNUstep runtime and stable poppler # Use another poppler-based viewer or gnustep-apps/gspdf instead # Removal in 30 days (bug #426268) gnustep-libs/popplerkit gnustep-apps/vindaloo
[gentoo-dev] Re: udev <-> mdev
Ian Stakenvicius posted on Mon, 16 Jul 2012 09:53:20 -0400 as excerpted: > ...if going this route, why not simply not bother to pivot_root out of > the initramfs at all? or pivot_root but only into a directory structure > still sitting in the initramfs? As long as all non-root bits are in > separate storage, you can mount 'em all in the appropriate place... I'm not sure whether that was asked of me or Maxim K, but that was beginning to be my conclusion as well. See the earlier comment about not even using an initr* at all, "tho this would be close". -- 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] multiple package moves into one
On Mon, Jul 16, 2012 at 8:49 AM, Ian Stakenvicius wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > On 15/07/12 06:16 PM, Zac Medico wrote: >> On 07/15/2012 03:08 PM, Doug Goldstein wrote: >>> Is it valid to do something like: >>> >>> move media-plugins/mytharchive media-plugins/mythplugins move >>> media-plugins/mythbrowser media-plugins/mythplugins move >>> media-plugins/mythgallery media-plugins/mythplugins move >>> media-plugins/mythgame media-plugins/mythplugins move >>> media-plugins/mythmovies media-plugins/mythplugins move >>> media-plugins/mythnews media-plugins/mythplugins move >>> media-plugins/mythweather media-plugins/mythplugins >> >> No, that's not really how it's intended to be used. You'll probably >> have to put blockers in media-plugins/mythplugins to block all the >> old packages that install the same files. > > Theoretically (i've done a quick test on this and it seems true) a > single-"!" blocker is enough that one package will on upgrade replace > all these others without user intervention being required (assuming > these packages aren't in @world, of course), and it won't cause file > collisions. > > Unrelatedly curious, why the package merge? Trying to make MythTV maintenance easier on myself since I couldn't find a maintainer. Upstream changed to SVN a long while back and with that changed moved all the plugins into one bundle called mythplugins. They've now switched to git and with that change I decided to modernize a little bit. mythtv.git a few top level directories, each of which is packaged as its own tarball which makes backporting patches extra fun. The mythplugins tarball (mythtv.git/mythplugins) contains additional plugins that are found in different git repos. They're still unique snowflakes with their git usage. -- Doug Goldstein
