Re: [gentoo-dev] Re: Let's redesign the entire filesystem!
Am 15.03.2012 00:37, schrieb Greg KH: > Not really, I don't think we support systems without udev anymore, > right? And we get away with a lot of these different "options" at > compile time, which makes it easier than what Debian has to handle, so > perhaps it's not a fair comparison. Sure Gentoo does support such systems... # equery g virtual/dev-manager * Searching for dev-manager in virtual ... * dependency graph for virtual/dev-manager-0 `-- virtual/dev-manager-0 amd64 `-- sys-fs/udev-171-r5 (sys-fs/udev) amd64 `-- sys-apps/busybox-1.19.3-r1 (sys-apps/busybox) amd64 [mdev] `-- sys-fs/devfsd-1.3.25-r9 (sys-fs/devfsd) [missing keyword] `-- sys-fs/static-dev-0.1 (sys-fs/static-dev) amd64 `-- sys-freebsd/freebsd-sbin-9.0 (sys-freebsd/freebsd-sbin) [missing keyword] [ virtual/dev-manager-0 stats: packages (6), max depth (1) ] /martin
Re: [gentoo-dev] Re: Let's redesign the entire filesystem!
On 03/14/2012 11:04, Greg KH wrote: > > Not always, no, it isn't obvious that something didn't start up > correctly, or that it didn't fully load properly. Some programs later > on recover and handle things better. I'm well aware of what I run on my own box, and when something isn't running, I figure it out pretty quickly. I tested udev-181 in a Gentoo VM that I put together recently, giving it a separate /usr, and made sure that CONFIG_DEVTMPFS was enbaled. The only service that failed to load properly at startup was udev, specifically because udevadm couldn't locate libkmod (likely because kmod installs into /usr/lib*, which wasn't available yet because I also don't use an initramfs in my kernel). Everything else worked fine, and udev later started properly once localmount was complete. I even tried, out of curiosity, to tweak things and moved udev from sysinit to boot and then to default runlevel. In 'boot', udevadm still fails to load, so no change. In 'default', only net.lo failed because the 'lo' device didn't yet exist until after udev was running. udev itself loaded fine, and the networking scripts restarted themselves. So with the one exception of networking, which in Linux, has never created /dev nodes (has to be some historical piece on why), one almost doesn't need udev at boot to even get things working on a very simple setup like mine. And since udev is the one service that didn't load correctly, one COULD put forth the hypothesis that it is udev that is "broken". But I doubt that will get much traction, right? This does lead me to wonder if a light-weight udev could exist that lacks half or more of the functionality of the current udev. I'll be honest, I've only edited my udev rules file once, and that was only when I installed a Sun Happy Meal quad ethernet card in which all four ports utilize the same MAC address and udev doesn't handle this very gracefully (if I had Solaris, I could edit the card's firmware and change this setting). Devtmpfs quite literally handles 98% of my particular usage scenario. Does that apply to everyone? Nope. Just an interesting observation. -- Joshua Kinard Gentoo/MIPS ku...@gentoo.org 4096R/D25D95E3 2011-03-28 "The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between." --Emperor Turhan, Centauri Republic signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Let's redesign the entire filesystem!
On Thu, 2012-03-15 at 00:29 +, David Leverton wrote: > On 14 March 2012 23:44, Greg KH wrote: > > Oh, and somehow "consensus" will work? No, sorry, it will not. > > No, logical analysis will, as I said in the rest of my post which you > conveniently ignored - either we conclude with evidence that there are > no issues, which should settle the matter for reasonable people, or we > discover that there are, in which case they have to be dealt with one > way or another. I really don't see how anyone can object to that, > unless they're worried they won't like the result > > > How about the basic FACT that today, such systems do not work > > This is debatable at best. You can keep screaming "but bluetooth > won't work!" until you're blue in the face, but that's not relevant at > all to people who don't use bluetooth. That's true, but given the need to have a "one size fits all" boot system(for obvious practical reasons), such boot system needs to work with bluetooth input devices -- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur. http://common-lisp.net/project/iolib signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: Let's redesign the entire filesystem!
On 03/14/2012 18:14, David Leverton wrote: > On 14 March 2012 21:04, Greg KH wrote: >> Haveing a separate /usr is wonderful, and once we finish moving /sbin/ >> and /bin/ into /usr/ it makes even more sense. See the /usr page at >> fedora for all of the great reasons why this is good. > > My point was examine, in detail, whether separate-/usr-with-initramfs > has any disadvantages compared to separate-/usr-without-initramfs. > Either it has, in which case we have a concrete argument against > requiring initramfs (albeit possibly one that can be fixed), or it > hasn't, which should hopefully convince at least some people to accept > it. I went with a split filesystem design when I built my first Gentoo install back in mid 2003 because at the time, both the Gentoo and Debian security guides referenced it as being an option for a more secure system. Specifically so that you could apply mount options to each partition. For example, on /home, you would usually want to do nodev and nosuid, because rarely does a user need the ability to create device nodes and SUID binaries. On /var, nodev, nosuid, and noexec, with the one exception if you ran qmail or a few other packages known to stick executables into /var. For /usr, the guides suggested just nodev, because you rarely, if ever need to create device nodes in /usr. Optionally, you could mount /usr ro and only make it rw if updating packages. You won't find A separate /usr mentioned specifically anymore in either security guide, but I'm sure if you dig on the Wayback Machine (once it comes back online), you can probably find these references. Search from 2003 to 2007. I'm not certain when they were removed. -- Joshua Kinard Gentoo/MIPS ku...@gentoo.org 4096R/D25D95E3 2011-03-28 "The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between." --Emperor Turhan, Centauri Republic signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Let's redesign the entire filesystem!
On 03/14/2012 18:51, Greg KH wrote: > On Wed, Mar 14, 2012 at 10:14:54PM +, David Leverton wrote: >> On 14 March 2012 21:04, Greg KH wrote: >>> Haveing a separate /usr is wonderful, and once we finish moving /sbin/ >>> and /bin/ into /usr/ it makes even more sense. See the /usr page at >>> fedora for all of the great reasons why this is good. >> >> My point was examine, in detail, whether separate-/usr-with-initramfs >> has any disadvantages compared to separate-/usr-without-initramfs. > > Oh, that's simple, separate-/usr-without-initramfs will not work and > will not be supported :) Not supported by whom? udev? Or Gentoo? -- Joshua Kinard Gentoo/MIPS ku...@gentoo.org 4096R/D25D95E3 2011-03-28 "The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between." --Emperor Turhan, Centauri Republic signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Let's redesign the entire filesystem!
On 03/15/2012 07:20, Stelian Ionescu wrote: > On Thu, 2012-03-15 at 00:29 +, David Leverton wrote: >> On 14 March 2012 23:44, Greg KH wrote: >>> Oh, and somehow "consensus" will work? No, sorry, it will not. >> >> No, logical analysis will, as I said in the rest of my post which you >> conveniently ignored - either we conclude with evidence that there are >> no issues, which should settle the matter for reasonable people, or we >> discover that there are, in which case they have to be dealt with one >> way or another. I really don't see how anyone can object to that, >> unless they're worried they won't like the result >> >>> How about the basic FACT that today, such systems do not work >> >> This is debatable at best. You can keep screaming "but bluetooth >> won't work!" until you're blue in the face, but that's not relevant at >> all to people who don't use bluetooth. > > That's true, but given the need to have a "one size fits all" boot > system(for obvious practical reasons), such boot system needs to work > with bluetooth input devices With Gentoo, that's really only for the preliminary installation. Once you get the system up and running, you're free to modify it in whatever way pleases you. For binary distributions, especially those that deal in the enterprise sector, the one-size-fits-all approach is damn near mandatory because most admins run with the distro-provided kernel and typically are not custom compiling them. But we're not a binary distro. We're a source-based distro, although it's possible to run Gentoo in a binary fashion. As such, we're not necessarily beholden to the "one-size-fits-all" approach. -- Joshua Kinard Gentoo/MIPS ku...@gentoo.org 4096R/D25D95E3 2011-03-28 "The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between." --Emperor Turhan, Centauri Republic signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Let's redesign the entire filesystem!
On 03/14/2012 20:45, Zac Medico wrote: > On 03/14/2012 05:36 PM, David Leverton wrote: >> On 14 March 2012 23:47, Zac Medico wrote: >>> It's more about what we're _not_ doing that what we're doing. >> >> Clearly something must have changed in udev 181 to make >> /usr-without-initramfs not work anymore, and someone must have done >> something to make that change happen, unless udev has aquired the >> ability to evolve by itself. > > You're pointing your finger at udev, but the udev change is just a > symptom of a more general shift away from supporting the "/ is a > self-contained boot disk that is independent of /usr" use case. I think it's better to say that udev is one of the more important components of your average Linux system that's decided to support a unified root + /usr filesystem. If we were looking at some non-critical, non-boot service that made this decision, then we wouldn't be having this discussion. -- Joshua Kinard Gentoo/MIPS ku...@gentoo.org 4096R/D25D95E3 2011-03-28 "The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between." --Emperor Turhan, Centauri Republic signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Let's redesign the entire filesystem!
On Thu, Mar 15, 2012 at 7:04 AM, Joshua Kinard wrote: > This does lead me to wonder if a light-weight udev could exist that lacks > half or more of the functionality of the current udev. I'll be honest, I've > only edited my udev rules file once, and that was only when I installed a > Sun Happy Meal quad ethernet card in which all four ports utilize the same > MAC address and udev doesn't handle this very gracefully (if I had Solaris, > I could edit the card's firmware and change this setting). You know - I had a similar issue, but with a pair of PL2303 USB RS232 interfaces. That makes me wonder if there is a possible way to enhance udev to better handle situations where devices have no unique ID and thus tend to be difficult to access consistently across reboots. In my case I had to hack a rule so that I got a symlink if the device was in a specific USB slot. Use case is controlling tuners for mythtv. No doubt a simpler 80% solution could be created for udev, and likely it would be easier to cut down on its dependencies as a result. However, the other 20% of users will still need the more complete solution. Big distros that want to support lots of hardware with a one-size-fits-all configuration will just deploy that complete solution everywhere, which means that the only people maintaining the simple solution would be people who like to tailor each system. For most of the more enterprise-y OS providers (ie the ones with money to pay devs), one-size-fits-all is a lot more sustainable. You won't find an edition of MS Windows that works only on PCs without scanners and sound but uses 50MB less RAM, for example. Sure, we don't have the same constraints as the enterprise-y distros, but we do have the constraint that if we want to do things differently we will spend a lot of time patching what we could otherwise simply reuse as-is. I don't think that split filesystem installs are going away anytime soon. In fact, when btrfs is finally mature we might see them blossum. Using subvolumes you could have more granular snapshotting and mount options, while still maintaining a shared disk space pool (with granular quotas). If everything the distro is likely to mangle is in a few subvolumes you can reverts snapshots on those without losing changes in other subvolumes if you ran in production before deciding to revert. That gets you a lot more flexibility than a single snapshot on root - especially in terms of recovery time (you can still copy files between snapshots if you only snapshotted root - in fact with reflinks this is very fast). Rich
Re: [gentoo-dev] Re: Let's redesign the entire filesystem!
On 03/14/2012 19:27, Richard Yao wrote: > On 03/14/12 18:49, Greg KH wrote: >> On Wed, Mar 14, 2012 at 06:39:05PM -0400, Richard Yao wrote: >>> With that said, I have a few questions: >>> >>> 1. Why does no one mention the enterprise use case at all? >> >> It has been pointed out before, why constantly repeat ourselves. > > Simple. No one has documented it. A webpage that makes a few vague > references to "enterprise use" does not count as documentation. > > I happened to figure it out when trying to rationalize why anyone would > want this, but this is hardly obvious to those that imagine a computer > as a self-sufficient single disk system. You'll also find a lot of enterprise-specific decisions went into IPv6, without necessarily stating them as being enterprise-specific. I.e., the requirement for Unique Local Addresses, which are IPv6's idea of RFC1918, required to be "globally-unique". When I quizzed someone about this one (I think it was on ServerFault somewhere), I was basically told that "IPv6 is not for home use". >>> 2. Why not make rootfs a NFS mount with a unionfs at the SAN/NAS device? >> >> unionfs is still a "work in progress", some systems can't do that yet. > > That sounds like something that needs to be fixed. I thought UnionFS died? Or was better handled by other "tricks" involving filesystem overlays? >>> 3. Why not let the users choose where these directories go and support >>> both locations? >> >> Because a plethera of options is a sure way to make sure that half of >> them don't work over the long run. >> >> We aren't Debian here people, we don't support "everything" :) > > Gentoo provides far more options than Debian does, so this seems > somewhat contradictory to me. Agreed. Debian is focused on an entirely different model of building a Linux system, thus they have a narrower dependency chain and you sometimes have to include packages that you don't necessarily care for because they're required by a package that you do want to use. We have USE flags to resolve that issue. -- Joshua Kinard Gentoo/MIPS ku...@gentoo.org 4096R/D25D95E3 2011-03-28 "The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between." --Emperor Turhan, Centauri Republic signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Let's redesign the entire filesystem!
On 03/14/2012 19:37, Greg KH wrote: > On Wed, Mar 14, 2012 at 07:27:07PM -0400, Richard Yao wrote: 3. Why not let the users choose where these directories go and support both locations? >>> >>> Because a plethera of options is a sure way to make sure that half of >>> them don't work over the long run. >>> >>> We aren't Debian here people, we don't support "everything" :) >> >> Gentoo provides far more options than Debian does, so this seems >> somewhat contradictory to me. > > Not really, I don't think we support systems without udev anymore, > right? And we get away with a lot of these different "options" at > compile time, which makes it easier than what Debian has to handle, so > perhaps it's not a fair comparison. I already looked in the tree and nothing really stands out as a suitable replacement for /dev management. mdev might, but it's part of busybox and not standalone as far as I know (at least, we don't have an independent package for it). For my simplistic setups, I apparently only need udev just to setup the networking interfaces, because Linux has never created /dev/lo or /dev/ethX (nor does it even support them). Thus, CONFIG_DEVTMPFS can't set those up at all. If I could find a small utility that was like udev and which took care of that one little element, I think I'd be able to boot my systems up just fine. Is it futureproof? Not really. I imagine plugging USB mass storage devices into a udevless system might be problematic. Food for thought. -- Joshua Kinard Gentoo/MIPS ku...@gentoo.org 4096R/D25D95E3 2011-03-28 "The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between." --Emperor Turhan, Centauri Republic signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Let's redesign the entire filesystem!
On 03/14/2012 16:55, Zac Medico wrote: >> Deprecation of this practice would mean that people could type >> /bin/command instead of /usr/bin/command in situations where absolute >> paths are necessary. We could symlink things in /usr to rootfs for >> compatibility with legacy software. In a more extreme case, we could >> symlink /usr to /, which would make plenty of sense given that we do not >> need a separate /usr at all. > > I'm not seeing any compelling benefits here that would justify a lack of > conformity with other *nix distros. It seems almost as though it's an > attempt to be different for the sake of being different, perhaps a > symptom of something like NIH syndrome. Gentoo, by its very nature, has always been regarded as somewhat non-conformist. When Gentoo first popped onto the scene, most other distros didn't do colors in the terminal. We did. And it all branches out from there. -- Joshua Kinard Gentoo/MIPS ku...@gentoo.org 4096R/D25D95E3 2011-03-28 "The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between." --Emperor Turhan, Centauri Republic signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Let's redesign the entire filesystem!
On 03/14/2012 13:59, Rich Freeman wrote: > On Wed, Mar 14, 2012 at 1:29 PM, Zac Medico wrote: >> On 03/14/2012 10:11 AM, Maxim Kammerer wrote: >>> What's wrong with: >>> * having an "early mounts" list file >>> * having an "early modules" list file >>> * init system in early boot (e.g., OpenRC in init.sh) loading "early >>> modules" and mounting "early mounts" from /etc/fstab >> >> You're assuming that the /sbin/init hasn't migrated to /usr/sbin/init. >> Other that that, it sounds like a perfect solution if you're in the "I'd >> rather die than use an initramfs" camp. > > Well, anybody is welcome to create any replacement/addition for > (/usr)/sbin/init or (/usr)/sbin/rc that they wish. If you make it > good enough, perhaps others will even use it. > > Beyond that, anything else is just a suggestion. In the end the folks > writing udev and systemd are writing code, which gets them a lot > further than emails do... :) Debian has a small, yet fairly unique little package called "file-rc" that replaces their more traditional init system with a single text file, /etc/runlevels, to manage system services. A small utility runs that parses the text file and sets up the /etc/rc.x symlinks for you, based on that file. Fairly novel little package. Wholly-incompatible with Gentoo's system, without fully replacing OpenRC, but I would actually be interested in seeing something like this on Gentoo (such as something that simply parses and executes rc-update to change things). http://packages.debian.org/squeeze/file-rc -- Joshua Kinard Gentoo/MIPS ku...@gentoo.org 4096R/D25D95E3 2011-03-28 "The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between." --Emperor Turhan, Centauri Republic signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Let's redesign the entire filesystem!
On 03/15/2012 08:30, Rich Freeman wrote: > > You know - I had a similar issue, but with a pair of PL2303 USB RS232 > interfaces. That makes me wonder if there is a possible way to > enhance udev to better handle situations where devices have no unique > ID and thus tend to be difficult to access consistently across > reboots. In my case I had to hack a rule so that I got a symlink if > the device was in a specific USB slot. Use case is controlling tuners > for mythtv. I use a ton of the pl2303-based devices, too. Except I'm usually in Windows with them, so I just have to deal with Window's oddball way of renumbering them sometimes when I unplug one and plug it right back into the same USB slot (i.e., I lost COM11, and it's now COM14, which, ironically, is outside the range of TeraTerm) > No doubt a simpler 80% solution could be created for udev, and likely > it would be easier to cut down on its dependencies as a result. > However, the other 20% of users will still need the more complete > solution. Big distros that want to support lots of hardware with a > one-size-fits-all configuration will just deploy that complete > solution everywhere, which means that the only people maintaining the > simple solution would be people who like to tailor each system. That, or udev making more of its functionality optional via its build system (does it use autotools and configure, I never looked, to be honest?). This would allow additional USE flags to be added to enable or disable additional functionality as needed. > For most of the more enterprise-y OS providers (ie the ones with money > to pay devs), one-size-fits-all is a lot more sustainable. You won't > find an edition of MS Windows that works only on PCs without scanners > and sound but uses 50MB less RAM, for example. Funny, but as much as I am against Windows on a server, Windows Server is easier to turn off unneeded stuff than RHEL5 is. Windows Server comes with audio and TWAIN/IMAPI components disabled (or out right missing -- you have to add them back in through server manager). But try to remove features like sound, CD burning, various media players, text-to-speech, etc, from a fresh RHEL5 install, and you're in for a fight. It's not necessarily RHEL's fault, but more Gnome's fault because of the massive about of interdependency that you get with Gnome, and the fact RH chose to just not bother with it and build in a ton of stuff by default. Ditto for an install of OpenSolaris that I did. > I don't think that split filesystem installs are going away anytime > soon. In fact, when btrfs is finally mature we might see them > blossum. Using subvolumes you could have more granular snapshotting > and mount options, while still maintaining a shared disk space pool > (with granular quotas). If everything the distro is likely to mangle > is in a few subvolumes you can reverts snapshots on those without > losing changes in other subvolumes if you ran in production before > deciding to revert. That gets you a lot more flexibility than a > single snapshot on root - especially in terms of recovery time (you > can still copy files between snapshots if you only snapshotted root - > in fact with reflinks this is very fast). ZFS encourages creating volumes and filesystems en masse. Right down to a separate ZFS mount for each user's home directory under /home, and /home itself is a mount point. So yeah, Btrfs, ZFS, etc...get an FS like those two which not only encourage dozens of mount points, but which seamlessly hide all the dirty details from you (and the users), and issues like this will simply vanish into thin air. -- Joshua Kinard Gentoo/MIPS ku...@gentoo.org 4096R/D25D95E3 2011-03-28 "The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between." --Emperor Turhan, Centauri Republic signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Let's redesign the entire filesystem! [was newsitem: unmasking udev-181]
On 03/14/2012 16:10, Kent Fredric wrote: > > Considering this pretty much eliminates using / for anything useful, > we might as well rename "/usr" "/c" > > Even if it /is/ just to confuse the windows crowd =) Unless you're one of those that installs Windows into D:\ :) I'd say call it /sys for NetWare's old SYS:\ volume, but that's already taken by sysfs. -- Joshua Kinard Gentoo/MIPS ku...@gentoo.org 4096R/D25D95E3 2011-03-28 "The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between." --Emperor Turhan, Centauri Republic signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: newsitem: unmasking udev-181
On 03/14/2012 17:13, Walter Dnes wrote: > On Wed, Mar 14, 2012 at 08:07:07AM -0400, Joshua Kinard wrote > >> Ah, bluetooth keyboards. The luddite in me finds those quite >> the oddity. I still use only PS/2, specifically because it's less >> complex and less likely to fail on me in a time of need. > > Unicomp has licenced manufacturing rights to the IBM Model M keyboard, > with USB adapter, of course. http://pckeyboard.com/page/product/UNI041A > Look Ma, no Windows keys! If you do want Windows keys, you can order > http://pckeyboard.com/page/product/UNI0P4A > > And if you want an original with PS/2 connector, they also offer > http://pckeyboard.com/page/category/IBMKBD I actually have an original IBM Model M. Manufacture date of July 22nd, 1987. And I use Windows on a regular basis. Yet, I get by without the windows key quite well. About the only two shortcuts I ever used were WIN+E and WIN+R, for Explorer and Run. It's not as useful of a key as many people think it is. It's actually more beneficial to those with disabilities, such as low or impaired vision. -- Joshua Kinard Gentoo/MIPS ku...@gentoo.org 4096R/D25D95E3 2011-03-28 "The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between." --Emperor Turhan, Centauri Republic signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Let's redesign the entire filesystem!
On 03/14/2012 12:28, Matthew Summers wrote: > > Gentoo provides a solution with genkernel, dracut provides a solution, > even the linux kernel itself provides a solution (in my view the > easiest solution at that). The kernel doesn't appear to create the networking interfaces, though. CONFIG_DEVTMPFS is only going to handle things that physically exist within /dev, of which, ethernet devices have always been excluded. If that can get fixed in some fashion, then devtmpfs pretty much does make this a non-issue. > I just wanted to drop this simple fact in there. This has been coming > for several years now AND the linux kernel has been using an initramfs > for every boot, every time for a long time now, all 2.6 and up as I > understand it. If the initramfs is empty, well the kernel is smart > enough to fall back on "legacy" boot process. initramfs was introduced in 2.6.10, and prior to that, only a handful of architectures even supported a built-in initrd (MIPS was one, and it wasn't very pretty or functional). I believe other distros required the bootloader to pass the initrd to them somehow, but having never used an initrd in that fashion, I don't know for certain. But yes, if you enable CONFIG_IKCONFIG_PROC, you're essentially turning on (or utilizing) an initramfs accessible via /proc. -- Joshua Kinard Gentoo/MIPS ku...@gentoo.org 4096R/D25D95E3 2011-03-28 "The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between." --Emperor Turhan, Centauri Republic signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Let's redesign the entire filesystem!
On 03/14/2012 14:56, Zac Medico wrote: > On 03/14/2012 11:36 AM, Maxim Kammerer wrote: >> On Wed, Mar 14, 2012 at 19:58, Matthew Summers >> wrote: >>> Why is an in-kernel initramfs so bad anyway? I am baffled. Its quite >>> nice to have a minimal recovery env in case mounting fails, etc, etc, >>> etc. >> >> There is nothing bad about initramfs. I think that you are misreading >> the arguments above. > > Whatever the arguments may be, the whole discussion boils down to the > fact that the only people who seem to have a "problem" are those that > have a separate /usr partition and simultaneously refuse to use an > initramfs. I refuse to use an initramfs as this point in time because I haven't had to use one in the past 10 years to get my Gentoo installs to boot. Right now, all three active Gentoo installs that I have (x86_64, Vbox, MIPS) boot *fine* with a separate /usr and no initramfs. That, in my opinion, is not "broke", despite statements made to the contrary. It only became "broke" when individuals not involved with Gentoo declared it to be "broke", and then back it up with use-case scenarios that are really only applicable to their distribution of choice. I'm not saying that I'll continue to not use an initramfs, but I would like for some Gentoo-specific reasoning to be offered as to why we have to follow along with this change. Constantly referring to Fedora or Freedesktop websites for their reasoning doesn't matter to me. I don't use Fedora nor do I use X11 (at least the server. I tunnel 2-5 X11 apps over SSH, however). -- Joshua Kinard Gentoo/MIPS ku...@gentoo.org 4096R/D25D95E3 2011-03-28 "The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between." --Emperor Turhan, Centauri Republic signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Let's redesign the entire filesystem!
On 03/14/2012 19:44, Greg KH wrote: > > Oh, and somehow "consensus" will work? No, sorry, it will not. If compelling arguments were used, yes, you can sometimes trigger people to change their minds and arrive at a consensus. But outright dismissing them as if that will make them disappear is what won't work. > So it's not a "we know best", it's a "it will not properly work > otherwise." Udev is the only package I have installed in my VM setup that fails at boot with a separate /usr and no initramfs. And that isn't even a fatal failure, but it is a failure none the less, at least by virtue of OpenRC flagging the fact that udev returned an error code. Everything else works fine. But it's not udev that is broke, is it? It's my setup, right? I've been wrong for the last 10 years? Why was this ever referenced then in the Security Handbook? See Code Listing 1.1: http://www.gentoo.org/doc/en/security/security-handbook.xml?part=1&chap=4 > It is strange to watch people somehow think that if they complain > enough, or feel strongly enough, something is going to change here to > make this basic fact go away. It's human nature to complain or otherwise voice dissent, especially when someone or something comes along and declares that what used to JustWork(TM) now NoLongerWorks(TM). Does that mean my dissent matters? Probably not. But that's not going to stop me from trying. -- Joshua Kinard Gentoo/MIPS ku...@gentoo.org 4096R/D25D95E3 2011-03-28 "The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between." --Emperor Turhan, Centauri Republic signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Let's redesign the entire filesystem!
On Thu, Mar 15, 2012 at 07:04:52AM -0400, Joshua Kinard wrote: > Devtmpfs quite literally handles 98% of my particular usage scenario. Does > that apply to everyone? Nope. Just an interesting observation. devtmpfs does not handle device permissions. As for a "smaller" udev, feel free to try, please realize that this that is what udev used to be, before it was fixed to work properly. udev is very small and compact, but patches to make it smaller are always welcome. There's always mudev if you don't want to run udev, good luck with that. greg k-h
Re: [gentoo-dev] Re: Let's redesign the entire filesystem!
On Thu, Mar 15, 2012 at 08:30:49AM -0400, Rich Freeman wrote: > You know - I had a similar issue, but with a pair of PL2303 USB RS232 > interfaces. That makes me wonder if there is a possible way to > enhance udev to better handle situations where devices have no unique > ID and thus tend to be difficult to access consistently across > reboots. In my case I had to hack a rule so that I got a symlink if > the device was in a specific USB slot. Use case is controlling tuners > for mythtv. Why not use the links in /dev/serial/ which are there for this specific reason? greg k-h
Re: [gentoo-dev] Re: Let's redesign the entire filesystem!
On 03/15/2012 05:27 AM, Joshua Kinard wrote: > On 03/14/2012 20:45, Zac Medico wrote: > >> On 03/14/2012 05:36 PM, David Leverton wrote: >>> On 14 March 2012 23:47, Zac Medico wrote: It's more about what we're _not_ doing that what we're doing. >>> >>> Clearly something must have changed in udev 181 to make >>> /usr-without-initramfs not work anymore, and someone must have done >>> something to make that change happen, unless udev has aquired the >>> ability to evolve by itself. >> >> You're pointing your finger at udev, but the udev change is just a >> symptom of a more general shift away from supporting the "/ is a >> self-contained boot disk that is independent of /usr" use case. > > > I think it's better to say that udev is one of the more important components > of your average Linux system that's decided to support a unified root + /usr > filesystem. If we were looking at some non-critical, non-boot service that > made this decision, then we wouldn't be having this discussion. They're intertwined though, since having a unified root implies that there is no support for the "/ is a self-contained boot disk that is independent of /usr" use case, and the bulk of people's opposition to having a unified root seems to stem from their dependence on the "/ is a self-contained boot disk that is independent of /usr" use case. So, the question at the heart of the whole discussion is: Should we support the "/ is a self-contained boot disk that is independent of /usr" use case? -- Thanks, Zac
[gentoo-dev] gentoo-news repository migrated to git
Seems that nobody has announced it yet: The gentoo-news repository has moved from subversion to git some time ago. New news items should be committed to git only, because the master rsync doesn't pull from the svn repository any more. Especially, this concerns the news about udev unmasking that was committed (to svn) yesterday. Ulrich
Re: [gentoo-dev] Re: Let's redesign the entire filesystem!
On Thu, Mar 15, 2012 at 10:42 AM, Greg KH wrote: > > Why not use the links in /dev/serial/ which are there for this specific > reason? > # ls -l /dev/serial ls: cannot access /dev/serial: No such file or directory Something in a newer version of udev perhaps? Or would my defining my own symlinks end up overriding some rule elsewhere. I just added these lines to /etc/udev/rules.d: SUBSYSTEM=="tty", DRIVERS=="pl2303", KERNELS=="4-1:1.0", KERNEL=="ttyUSB*", SYMLINK="mythser/rca1" SUBSYSTEM=="tty", DRIVERS=="pl2303", KERNELS=="3-3:1.0", KERNEL=="ttyUSB*", SYMLINK="mythser/rca2" Rich
Re: [gentoo-dev] gentoo-news repository migrated to git
On Thu, 15 Mar 2012 19:28:03 +0100 Ulrich Mueller wrote: > Seems that nobody has announced it yet: > > The gentoo-news repository has moved from subversion to git some time > ago. New news items should be committed to git only, because the > master rsync doesn't pull from the svn repository any more. > > Especially, this concerns the news about udev unmasking that was > committed (to svn) yesterday. Can we make svn read-only then? -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] gentoo-news repository migrated to git
On Thu, Mar 15, 2012 at 2:28 PM, Ulrich Mueller wrote: > The gentoo-news repository has moved from subversion to git some time > ago. New news items should be committed to git only, because the > master rsync doesn't pull from the svn repository any more. > Is there a link to the repository anywhere? I don't see one on g.o, but I might not be looking in the right place. Might not hurt to include instructions on how to push to it as well... Rich
[gentoo-dev] /dev/serial/ (was "Let's redesign the entire filesystem!")
On Thu, Mar 15, 2012 at 03:04:36PM -0400, Rich Freeman wrote: > On Thu, Mar 15, 2012 at 10:42 AM, Greg KH wrote: > > > > Why not use the links in /dev/serial/ which are there for this specific > > reason? > > > > # ls -l /dev/serial > ls: cannot access /dev/serial: No such file or directory Do you have your serial device plugged in? If not, it will not show up. > Something in a newer version of udev perhaps? It went into udev version 136, way back in 2008, so odds are, you have it on your system... > Or would my defining my > own symlinks end up overriding some rule elsewhere. I just added > these lines to /etc/udev/rules.d: > SUBSYSTEM=="tty", DRIVERS=="pl2303", KERNELS=="4-1:1.0", > KERNEL=="ttyUSB*", SYMLINK="mythser/rca1" > SUBSYSTEM=="tty", DRIVERS=="pl2303", KERNELS=="3-3:1.0", > KERNEL=="ttyUSB*", SYMLINK="mythser/rca2" You do know that USB buses can be dynamically renumbered depending on the phase of the moon, right? Be careful here... greg k-h
Re: [gentoo-dev] /dev/serial/ (was "Let's redesign the entire filesystem!")
On Thu, Mar 15, 2012 at 3:17 PM, Greg KH wrote: > On Thu, Mar 15, 2012 at 03:04:36PM -0400, Rich Freeman wrote: >> # ls -l /dev/serial >> ls: cannot access /dev/serial: No such file or directory > > Do you have your serial device plugged in? If not, it will not show up. > Yup - it is plugged in, and the links in /dev/mythser show up fine. Since I've been recording my TV shows on the correct channels I have to assume the devices are working fine too. > You do know that USB buses can be dynamically renumbered depending on > the phase of the moon, right? Be careful here... Hmm - this has been stable for me for years, compared to just using /dev/ttyUSBn. In any case, I have no idea why nothing shows up in /dev/serial. The only device nodes I can find for serial are /dev/ttyUSBn and /dev/mythser/n (the latter being from my own rules). Rich
Re: [gentoo-dev] gentoo-news repository migrated to git
> On Thu, 15 Mar 2012, Rich Freeman wrote: >> The gentoo-news repository has moved from subversion to git some >> time ago. New news items should be committed to git only, because >> the master rsync doesn't pull from the svn repository any more. > Is there a link to the repository anywhere? I don't see one on g.o, > but I might not be looking in the right place. > Might not hurt to include instructions on how to push to it as > well... Sorry, I should have mentioned that of course. git://anongit.gentoo.org/proj/gentoo-news.git git+ssh://g...@git.gentoo.org/proj/gentoo-news.git Ulrich
Re: [gentoo-dev] Re: Let's redesign the entire filesystem!
On 03/15/12 08:40, Joshua Kinard wrote: > I already looked in the tree and nothing really stands out as a suitable > replacement for /dev management. mdev might, but it's part of busybox and > not standalone as far as I know (at least, we don't have an independent > package for it). Busybox is installed as part of the system profile on amd64. You can install mdev by doing this: ln -s /bin/busybox /sbin/mdev There is documentation in the busybox GIT for how to use it: http://git.busybox.net/busybox/plain/docs/mdev.txt signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Let's redesign the entire filesystem!
On 03/15/12 08:34, Joshua Kinard wrote: > On 03/14/2012 19:27, Richard Yao wrote: > >> On 03/14/12 18:49, Greg KH wrote: 2. Why not make rootfs a NFS mount with a unionfs at the SAN/NAS device? >>> >>> unionfs is still a "work in progress", some systems can't do that yet. >> >> That sounds like something that needs to be fixed. > > > I thought UnionFS died? Or was better handled by other "tricks" involving > filesystem overlays? I know the UnionFS developer offline. I will ask him what the status of unionFS is the next time I see him. :) signature.asc Description: OpenPGP digital signature
[gentoo-dev] lurking *.ebuild'less packages
slep noticed and reported an odd thing: $ euse -i kate ... ls: cannot access /gentoo/portage/metadata/cache/kde-base/kdebindings-perl-*: No such file or directory ls: cannot access /gentoo/portage/metadata/cache/kde-base/kdebindings-ruby-*: No such file or directory ... The dirs they don't contain ebuilds. Only metadata. KDE team is aware and fixing their orphans. I've decided to write a hack to find such instances in tree: $ ./find_empty.sh ~/portage/gentoo-x86/ kde-base/kdeaccessibility-colorschemes kde-base/kdeaccessibility-iconthemes kde-base/kdebase-wallpapers kde-base/kdebindings-csharp kde-base/kdebindings-perl kde-base/kdebindings-ruby kde-base/kvtml-data kde-base/smoke media-plugins/mytharchive media-plugins/mythbrowser media-plugins/mythgallery media-plugins/mythgame media-plugins/mythmovies media-plugins/mythmusic media-plugins/mythnetvision media-plugins/mythnews media-plugins/mythweather x11-themes/mythtv-themes Is there any reason to leave such ebuildless directories? Thanks! -- Sergei find_empty.sh Description: application/shellscript signature.asc Description: PGP signature
Re: [gentoo-dev] lurking *.ebuild'less packages
On 03/15/2012 10:59 PM, Sergei Trofimovich wrote: slep noticed and reported an odd thing: $ euse -i kate ... ls: cannot access /gentoo/portage/metadata/cache/kde-base/kdebindings-perl-*: No such file or directory ls: cannot access /gentoo/portage/metadata/cache/kde-base/kdebindings-ruby-*: No such file or directory ... The dirs they don't contain ebuilds. Only metadata. KDE team is aware and fixing their orphans. I've decided to write a hack to find such instances in tree: $ ./find_empty.sh ~/portage/gentoo-x86/ kde-base/kdeaccessibility-colorschemes kde-base/kdeaccessibility-iconthemes kde-base/kdebase-wallpapers kde-base/kdebindings-csharp kde-base/kdebindings-perl kde-base/kdebindings-ruby kde-base/kvtml-data kde-base/smoke media-plugins/mytharchive media-plugins/mythbrowser media-plugins/mythgallery media-plugins/mythgame media-plugins/mythmovies media-plugins/mythmusic media-plugins/mythnetvision media-plugins/mythnews media-plugins/mythweather x11-themes/mythtv-themes Is there any reason to leave such ebuildless directories? Thanks! You are talking about http://bugs.gentoo.org/371947
Re: [gentoo-dev] Deprecate EAPI1?
On Monday 12 of March 2012 01:49:35 Brian Harring wrote: > On Sun, Mar 11, 2012 at 04:14:33PM +0100, Ch??-Thanh Christopher Nguy???n wrote: > > Ciaran McCreesh schrieb: > > >> Is there really much of a benefit to this? I guess for anybody who > > >> runs scripts to mass-manipulate ebuilds it might be helpful, but I > > >> think all the package managers planned on supporting all the EAPIs for > > >> quite a while longer. > > > > > > We have to support them indefinitely. It's not possible to uninstall a > > > package whose EAPI is unknown. > > > > Would it be feasible to do a pkg_pretend() check and refuse > > install/upgrade if packages with unsupported EAPI are detected? > > The question should be "is it worth doing it", rather than "can we > hack out something". > > As Ciaran said, PM's are going to be supporting EAPI1 indefinitely In principle, it's actually entirely possible for any PM to start supporting exclusively completely API and ABI-breaking EAPI. There's always the problem with self-upgrading software as it needs to somehow predict (and limit) its development to keep upgrade paths. We have this exact problem where I work (with updating basestation SW) and some solution for this software is to stop being self-upgrading. With external upgrade tool (which would rsync package tree do any vdb/metadata-magic needed) one could replace current PM with latest, API/ABI- incompatible PM version. Now, it may not really make sense for PM as upgrade process of PM itself isn't any different from upgrade process of any other package, still it would allow any API/ABI-breaking ebuild format changes to be introduced if we really need them so badly. -- regards MM signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] lurking *.ebuild'less packages
On Thu, Mar 15, 2012 at 4:59 PM, Sergei Trofimovich wrote: > slep noticed and reported an odd thing: > > $ euse -i kate > ... > ls: cannot access /gentoo/portage/metadata/cache/kde-base/kdebindings-perl-*: > No such file or directory > ls: cannot access /gentoo/portage/metadata/cache/kde-base/kdebindings-ruby-*: > No such file or directory > ... > > The dirs they don't contain ebuilds. Only metadata. > KDE team is aware and fixing their orphans. > > I've decided to write a hack to find such instances in tree: > > $ ./find_empty.sh ~/portage/gentoo-x86/ > kde-base/kdeaccessibility-colorschemes > kde-base/kdeaccessibility-iconthemes > kde-base/kdebase-wallpapers > kde-base/kdebindings-csharp > kde-base/kdebindings-perl > kde-base/kdebindings-ruby > kde-base/kvtml-data > kde-base/smoke > media-plugins/mytharchive > media-plugins/mythbrowser > media-plugins/mythgallery > media-plugins/mythgame > media-plugins/mythmovies > media-plugins/mythmusic > media-plugins/mythnetvision > media-plugins/mythnews > media-plugins/mythweather > x11-themes/mythtv-themes > > Is there any reason to leave such ebuildless directories? > > Thanks! > > -- > > Sergei Let's get this script added to http://qa-reports.gentoo.org/
Re: [gentoo-dev] Re: newsitem: unmasking udev-181
On Thu, Mar 15, 2012 at 09:10:50AM -0400, Joshua Kinard wrote: > I actually have an original IBM Model M. Manufacture date of July 22nd, > 1987. And I use Windows on a regular basis. Yet, I get by without the > windows key quite well. About the only two shortcuts I ever used were WIN+E > and WIN+R, for Explorer and Run. It's not as useful of a key as many people > think it is. It's actually more beneficial to those with disabilities, such > as low or impaired vision. And for remapping as a Meta key... -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee & Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
Re: [gentoo-dev] Re: Let's redesign the entire filesystem!
On Thu, Mar 15, 2012 at 22:45, Richard Yao wrote: > I know the UnionFS developer offline. I will ask him what the status of > unionFS is the next time I see him. :) Unionfs patchset is regularly released for new kernels, and bugs are fixed. I wouldn't call the project "dead", I would call it "mature" and "stable". I am not aware of the current state of affairs wrt. Unionfs vs. aufs, and whether the propaganda at unionfs.org still holds water, though. Too bad that there is no stacking filesystem in the mainline kernel. -- Maxim Kammerer Liberté Linux (discussion / support: http://dee.su/liberte-contribute)
Re: [gentoo-dev] Re: Let's redesign the entire filesystem!
On 03/15/2012 10:41, Greg KH wrote: > > There's always mudev if you don't want to run udev, good luck with that. Got a link? We don't have anything matching in the tree, and Google turns up nothing relevant in the first few pages. -- Joshua Kinard Gentoo/MIPS ku...@gentoo.org 4096R/D25D95E3 2011-03-28 "The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between." --Emperor Turhan, Centauri Republic signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Let's redesign the entire filesystem!
On Wed, Mar 14, 2012 at 7:07 PM, Rich Freeman wrote: > On Wed, Mar 14, 2012 at 7:51 PM, Richard Yao wrote: >> >> I proposed a way that this could work with no effort on the part of the >> Gentoo developers in one of my earlier emails: >> > > Then go ahead and make it happen. If as you say no dev participation > is needed there is nothing Gentoo needs to do to support this. > > On Wed, Mar 14, 2012 at 6:49 PM, Greg KH wrote: >> >> We aren't Debian here people, we don't support "everything" :) >> >> If you want to support both, great, feel free to step up and do the >> work. >> > > Gentoo is about choice, but it is largely about the choices that > people are willing to step up and maintain. > > A few months ago there was a big thread and lots of devs said that > systemd isn't supported on Gentoo. Some devs stepped up and decided > to maintain it and now I'd say systemd is about as supported on Gentoo > as Prefix, FreeBSD, Sparc, or MIPS. That didn't happen because of > mailing list persuasion - it happened because a few people interested > in making it happen wrote a bunch of ebuilds. How do systemd units > end up in various packages? The people interested in seeing them > write good-quality patches and submit bugs, or otherwise work with the > maintainers to commit them. > > For those who don't like the current direction, by all means create an > overlay called udev-root, mdev-boot, noinitramfs, or whatever. You > don't need anybody's permission to do it - just go on github and make > it happen. Write some good code. There are several devs here who > might even help you out with it, and nobody here is going to object to > packages going into the main tree as long as they're maintained in > accordance with Gentoo QA. Create some USE flags where you need > tie-ins to other system packages and as long as everything behaves > nicely and patches are good and maintained, I'm sure the package > maintainers will accept them. In that vein... just to let you guys know that I have set up an overlay that has allowed me to run my Gentoo machines with only systemd: no OpenRC, no baselayout, no sysvinit: http://xochitl.matem.unam.mx/~canek/gentoo-systemd-only/ The changes are rather minimal (less than ten lines (usually a cople) per ebuild changed from the original ebuilds in the tree), and almost all will go away when the following bugs get fixed: https://bugs.gentoo.org/show_bug.cgi?id=366173 https://bugs.gentoo.org/show_bug.cgi?id=373219 https://bugs.gentoo.org/show_bug.cgi?id=373219 https://bugs.gentoo.org/show_bug.cgi?id=373219 https://bugs.gentoo.org/show_bug.cgi?id=399615 https://bugs.gentoo.org/show_bug.cgi?id=399615 https://bugs.gentoo.org/show_bug.cgi?id=399615 https://bugs.gentoo.org/show_bug.cgi?id=405703 https://bugs.gentoo.org/show_bug.cgi?id=408379 Bug 373219 is specially problematic, since several scripts in packages on the tree source /etc/init.d/functions.sh, (which lives in OpenRC), and don't depend on OpenRC explicitly. I wrote a little script that replaces the einfo, ewarn, etc. functions of OpenRC, and it seems to be working. I also wrote alternative versions of the packages on the tree that implicitly depend on OpenRC, so they now explicitly depend on a little package that only installs my script. It seems to be working. If you guys want to try it, I would love to hear some comments about it. (Usual disclaimer; if it breaks, you get to keep all the pieces). Oh, and obviously the only supported setups are those with /usr in the same partition as /; or, if /usr is in a separated partition, systems that use an initramfs to mount it. Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
Re: [gentoo-dev] Re: Let's redesign the entire filesystem!
On Thu, Mar 15, 2012 at 7:17 PM, Canek Peláez Valdés wrote: [...] > https://bugs.gentoo.org/show_bug.cgi?id=366173 > https://bugs.gentoo.org/show_bug.cgi?id=373219 > https://bugs.gentoo.org/show_bug.cgi?id=399615 > https://bugs.gentoo.org/show_bug.cgi?id=405703 > https://bugs.gentoo.org/show_bug.cgi?id=408379 Oops, sorry, fogot to use uniq. Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
Re: [gentoo-dev] Re: Let's redesign the entire filesystem!
On Thu, Mar 15, 2012 at 08:47:12PM -0400, Joshua Kinard wrote: > On 03/15/2012 10:41, Greg KH wrote: > > > > > There's always mudev if you don't want to run udev, good luck with that. > > > Got a link? We don't have anything matching in the tree, and Google turns > up nothing relevant in the first few pages. Sorry, I think it's called 'mdev' and is part of busybox. greg "no one asked me to adopt a package, amazing" k-h
Re: [gentoo-dev] lurking *.ebuild'less packages
Am Donnerstag, 15. März 2012, 21:59:44 schrieb Sergei Trofimovich:
> ls: cannot access
> /gentoo/portage/metadata/cache/kde-base/kdebindings-perl-*: No such file
> or directory ls: cannot access
> /gentoo/portage/metadata/cache/kde-base/kdebindings-ruby-*: No such file
> or directory ...
In the case of kde ebuilds it's a slip-up, a side effect of kde-4.6 removal...
some code got refactored and moved to different package names. E.g.
kdebindings-ruby is now partly in korundum and krossruby... When one of us
then runs
find kde-base -name *4.6.5*ebuild -exec cvs rm -f {} +
and commits, oops, suddenly we have an empty dir kdebindings-ruby... :|
Obviously undesired but can happen, and repoman does not complain (yet).
(It makes no sense to do any last-riting here, in effect this is more like a
package move and we try to make it as transparent to the users as possible.)
Cheers, A
--
Andreas K. Huettel
Gentoo Linux developer
kde, sci, tex, arm, printing
dilfri...@gentoo.org
http://www.akhuettel.de/
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: Let's redesign the entire filesystem!
On 03/15/12 22:43, Greg KH wrote: > On Thu, Mar 15, 2012 at 08:47:12PM -0400, Joshua Kinard wrote: >> On 03/15/2012 10:41, Greg KH wrote: >> >>> >>> There's always mudev if you don't want to run udev, good luck with that. >> >> >> Got a link? We don't have anything matching in the tree, and Google turns >> up nothing relevant in the first few pages. > > Sorry, I think it's called 'mdev' and is part of busybox. > > greg "no one asked me to adopt a package, amazing" k-h How about app-editors/bvi? signature.asc Description: OpenPGP digital signature
