[gentoo-dev] [RFC] /etc/resolv.conf symlink through net-dns/resolvconf-symlink
Hello, Many modern systems have their /etc/resolv.conf files autogenerated at runtime with DHCP, PPP or so on. Thus, storing that file in /etc seems no longer correct as that directory may be mounted read-only. I'm attaching a net-dns/resolvconf-symlink ebuild which replaces /etc/resolv.conf with a symlink to a runtime-writable location when installed. That package could be added to PDEPEND of packages like net-misc/networkmanager or net-dns/openresolv. Right now, that location is /var/run/resolv.conf. Using /run seems better for it but that directory is not yet in our baselayout. The package has USE=symlink which could be disabled by users which want to keep /etc/resolv.conf as-is. Right now, pkg_preinst() ensures that /etc/resolv.conf is autogenerated (tested with resolvconf and networkmanager) or doesn't exist and refuses to install otherwise. In future, this will be expanded to support more cases if necessary. In addition to that, pkg_preinst() and pkg_postrm() handle moving resolv.conf there and back to avoid leaving user with no nameservers. I also covered a similar idea in bug #377595 [1]. [1]:https://bugs.gentoo.org/show_bug.cgi?id=377595 -- Best regards, Michał Górny resolvconf-symlink-0.ebuild Description: Binary data signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] /etc/resolv.conf symlink through net-dns/resolvconf-symlink
On Wed, 10 Aug 2011 11:55:19 +0200 Michał Górny mgo...@gentoo.org wrote: Hello, Many modern systems have their /etc/resolv.conf files autogenerated at runtime with DHCP, PPP or so on. Thus, storing that file in /etc seems no longer correct as that directory may be mounted read-only. Hi Michał! While i don't disagree on that move i'm suspocious about the whole /etc/ ro mode. I don't think it's usable right now. Is your main goal to make it working by default? [assuming it is] What is the plan of other volatile stuff in /etc? - /etc/mtab - /etc/mtab.fuselock - /etc/blkid* - /etc/adjtime? Move to /var for default setup as well? Thanks. -- Sergei signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] /etc/resolv.conf symlink through net-dns/resolvconf-symlink
On Wed, 10 Aug 2011 13:37:30 +0300 Sergei Trofimovich sly...@gentoo.org wrote: On Wed, 10 Aug 2011 11:55:19 +0200 Michał Górny mgo...@gentoo.org wrote: Hello, Many modern systems have their /etc/resolv.conf files autogenerated at runtime with DHCP, PPP or so on. Thus, storing that file in /etc seems no longer correct as that directory may be mounted read-only. While i don't disagree on that move i'm suspocious about the whole /etc/ ro mode. I don't think it's usable right now. Is your main goal to make it working by default? I would really like to do so but I don't think I have enough power to do so. Right now, I'm running one machine with read-only root and resolv.conf was the only really problematic file for it. [assuming it is] What is the plan of other volatile stuff in /etc? - /etc/mtab I personally symlink it to /proc/mounts as I don't need additional features it provides. - /etc/mtab.fuselock Never heard of this one. But I guess it's FUSE-specific and thus easy to move. I guess you can open a bugreport for it. - /etc/blkid* That one's udev specific? I guess it could be moved as well. - /etc/adjtime? I was never sure what this is for. Does it really need to be updated randomly during runtime or once is enough? Move to /var for default setup as well? I'd personally prefer /run instead of /var for things that aren't supposed to last longer than for a single boot. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] /etc/resolv.conf symlink through net-dns/resolvconf-symlink
Many modern systems have their /etc/resolv.conf files autogenerated at runtime with DHCP, PPP or so on. Thus, storing that file in /etc seems no longer correct as that directory may be mounted read-only. While i don't disagree on that move i'm suspocious about the whole /etc/ ro mode. I don't think it's usable right now. Is your main goal to make it working by default? I would really like to do so but I don't think I have enough power to do so. Right now, I'm running one machine with read-only root and resolv.conf was the only really problematic file for it. Ah, i see. - /etc/blkid* That one's udev specific? I guess it could be moved as well. It's a blkid(8) cache to mount stuff by uuid/label and guess FS. Used at least by udev rules and stuff linked against libblkid (fsck.*). Both can be triggered at any time later after boot. blkid(8) can work w/o cache. - /etc/adjtime? I was never sure what this is for. Does it really need to be updated randomly during runtime or once is enough? It's saved/restored by hwclock(8) when system shutdowns/starts. In theory hwclock can be reran time to time on running system, but i don't think it's common. In-kernel copy of clock skew is expected to be maintained by ntp-alike daemon. -- Sergei signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] /etc/resolv.conf symlink through net-dns/resolvconf-symlink
On Wed, 10 Aug 2011 14:28:09 +0300 Sergei Trofimovich sly...@gentoo.org wrote: Many modern systems have their /etc/resolv.conf files autogenerated at runtime with DHCP, PPP or so on. Thus, storing that file in /etc seems no longer correct as that directory may be mounted read-only. While i don't disagree on that move i'm suspocious about the whole /etc/ ro mode. I don't think it's usable right now. Is your main goal to make it working by default? I would really like to do so but I don't think I have enough power to do so. Right now, I'm running one machine with read-only root and resolv.conf was the only really problematic file for it. Ah, i see. - /etc/blkid* That one's udev specific? I guess it could be moved as well. It's a blkid(8) cache to mount stuff by uuid/label and guess FS. Used at least by udev rules and stuff linked against libblkid (fsck.*). Both can be triggered at any time later after boot. blkid(8) can work w/o cache. 'Cache' is the key-word here. I suggest pinging upstream that /var/cache is there for some reason. - /etc/adjtime? I was never sure what this is for. Does it really need to be updated randomly during runtime or once is enough? It's saved/restored by hwclock(8) when system shutdowns/starts. In theory hwclock can be reran time to time on running system, but i don't think it's common. In-kernel copy of clock skew is expected to be maintained by ntp-alike daemon. Ah, then it should be stored in /var indeed. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] /usr vs. initramfs redux
On Fri, Aug 05, 2011 at 12:46:04AM +, Robin H. Johnson wrote: The minimal initramfs would do the following. 1. Mount devtmpfs/sysfs/procfs as needed to access devices. 2. Mount real_root to /newroot 3. Read /newroot/etc/initramfs.mount and /newroot/etc/fstab 4.1. If /newroot/etc/initramfs.mount does not exist Assume it contains only: /usr /var 5. Mount the combined items from said files Should these be mounted rread-only or just mounted? Also, will fsck still work if they are mounted? I am concerned about /var being included in this because of the potential of filling up the root partition. Upstream is only talking about /usr as stated earlier in this thread, so how are we getting /var involved? William pgpa44d2SZxQO.pgp Description: PGP signature
Re: [gentoo-dev] /usr vs. initramfs redux
On Wed, Aug 10, 2011 at 11:49:38AM -0500, William Hubbs wrote: On Fri, Aug 05, 2011 at 12:46:04AM +, Robin H. Johnson wrote: The minimal initramfs would do the following. 1. Mount devtmpfs/sysfs/procfs as needed to access devices. 2. Mount real_root to /newroot 3. Read /newroot/etc/initramfs.mount and /newroot/etc/fstab 4.1. If /newroot/etc/initramfs.mount does not exist Assume it contains only: /usr /var 5. Mount the combined items from said files Should these be mounted rread-only or just mounted? Also, will fsck still work if they are mounted? read-only. Yes, this does mean that the fsck code needs some improving, and potentially if it makes changes on a ro-mounted disk, the disk needs to be umounted remounted, or a reboot needs to happen. Basically what we do for / now needs to extend to the other mountpoints as well. I am concerned about /var being included in this because of the potential of filling up the root partition. Err, I don't follow. How does mounting /var fill up the root partition? Upstream is only talking about /usr as stated earlier in this thread, so how are we getting /var involved? See my other notes on stuff in udev rules that require /var before they can complete successfully. -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85
Re: [gentoo-dev] [RFC] /etc/resolv.conf symlink through net-dns/resolvconf-symlink
On Wed, Aug 10, 2011 at 01:32:12PM +0200, Michał Górny wrote: That one's udev specific? I guess it could be moved as well. It's a blkid(8) cache to mount stuff by uuid/label and guess FS. Used at least by udev rules and stuff linked against libblkid (fsck.*). Both can be triggered at any time later after boot. blkid(8) can work w/o cache. 'Cache' is the key-word here. I suggest pinging upstream that /var/cache is there for some reason. It was historically in /etc because it got used to mount /var. As an example, if you grab some RHEL systems on the default install, every entry in the fstab is UUID=... rather than fixed devices. Not having the cache the mounts will still work, but will be very slow as all devices will be rescanned. -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85
Re: [gentoo-dev] [RFC] /etc/resolv.conf symlink through net-dns/resolvconf-symlink
On Wed, Aug 10, 2011 at 4:06 PM, Robin H. Johnson robb...@gentoo.org wrote: On Wed, Aug 10, 2011 at 01:32:12PM +0200, Michał Górny wrote: That one's udev specific? I guess it could be moved as well. It's a blkid(8) cache to mount stuff by uuid/label and guess FS. Used at least by udev rules and stuff linked against libblkid (fsck.*). Both can be triggered at any time later after boot. blkid(8) can work w/o cache. 'Cache' is the key-word here. I suggest pinging upstream that /var/cache is there for some reason. It was historically in /etc because it got used to mount /var. As an example, if you grab some RHEL systems on the default install, every entry in the fstab is UUID=... rather than fixed devices. Not having the cache the mounts will still work, but will be very slow as all devices will be rescanned. I would think that something like this would change so infrequently as to not matter much. If you're going to actually install new block devices relevant to the boot process, I have to think that somewhere along the lines you'll probably need to mount /etc read-write. mdadm.conf is in a similar boat. So is fstab for that matter (my fstab probably changes more often than the list of permanent block devices does). Note that dracut at least expects to find some of this stuff on /etc. Much of the key stuff gets copied to the initramfs, but dracut actually tries to remount things according to whatever rules it finds in /etc/fstab so that it can respect stuff like noatime, etc. Now, right now that logic only applies to root, since that is all dracut tries to mount right now. Rich
Re: [gentoo-dev] [RFC] /etc/resolv.conf symlink through net-dns/resolvconf-symlink
On Wed, Aug 10, 2011 at 04:13:16PM -0400, Rich Freeman wrote: It was historically in /etc because it got used to mount /var. As an example, if you grab some RHEL systems on the default install, every entry in the fstab is UUID=... rather than fixed devices. Not having the cache the mounts will still work, but will be very slow as all devices will be rescanned. I would think that something like this would change so infrequently as to not matter much. If you're going to actually install new block devices relevant to the boot process, I have to think that somewhere along the lines you'll probably need to mount /etc read-write. It can change more often than you realize in some more enterprisy situations. The one that I've seen the most was a fibrechannel SAN, where the disk order varied with the response time of the devices (first-come first-serve in allocation of device nodes). Alternatively booting with USB/Firewire storage devices attached, if those storage modules are loaded before whatever other controller, it will vary depending what you have attached. mdadm.conf is in a similar boat. So is fstab for that matter (my fstab probably changes more often than the list of permanent block devices does). mdadm.conf is less of a concern as it's written by the user, not the system, and it contains just UUIDs and scans devices directly to assemble. -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85
Re: [gentoo-dev] [RFC] /etc/resolv.conf symlink through net-dns/resolvconf-symlink
On Wed, 10 Aug 2011 20:06:28 + Robin H. Johnson robb...@gentoo.org wrote: On Wed, Aug 10, 2011 at 01:32:12PM +0200, Michał Górny wrote: That one's udev specific? I guess it could be moved as well. It's a blkid(8) cache to mount stuff by uuid/label and guess FS. Used at least by udev rules and stuff linked against libblkid (fsck.*). Both can be triggered at any time later after boot. blkid(8) can work w/o cache. 'Cache' is the key-word here. I suggest pinging upstream that /var/cache is there for some reason. It was historically in /etc because it got used to mount /var. As an example, if you grab some RHEL systems on the default install, every entry in the fstab is UUID=... rather than fixed devices. Not having the cache the mounts will still work, but will be very slow as all devices will be rescanned. I guess /run would be the correct modern location for it then. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] /usr vs. initramfs redux
Robin H. Johnson wrote: On Wed, Aug 10, 2011 at 11:49:38AM -0500, William Hubbs wrote: I am concerned about /var being included in this because of the potential of filling up the root partition. Err, I don't follow. How does mounting /var fill up the root partition? If you take /var off its own partition and put it on /, then it will fill up / instead of /var. Filling up /var, not the end of the world. Filling up / is a bad thing. BTW, I have /var on its own partition. This moving things to / and not being able to have /usr, /var and such makes me really nervous. I have about double the needed space on /var and I still have had it fill up not once but several times. Think OOo build here. If /var didn't have its own partition, I would have had a crashed system and would have had to use a another bootable medium to clean out some stuff so it would boot again. I'm just glad I am setting at my system. If it was remote, I would be VERY pissed at whoever started this / only stuff. I guess next /home will have to be on / too. Since everything else is moving that way, why not. May as well lose everything and be done with it. Right? Just a users point of view. A long time Gentoo user I might add. I still have my 1.4 CD. Dale :-) :-)
Re: [gentoo-dev] /usr vs. initramfs redux
On Wed, Aug 10, 2011 at 03:47:18PM -0500, Dale wrote: On Wed, Aug 10, 2011 at 11:49:38AM -0500, William Hubbs wrote: I am concerned about /var being included in this because of the potential of filling up the root partition. Err, I don't follow. How does mounting /var fill up the root partition? If you take /var off its own partition and put it on /, then it will fill up / instead of /var. Filling up /var, not the end of the world. Filling up / is a bad thing. [snip] That is clear, but entirely irrelevant to my question. I _explicitly_ support /var on a partition, that's why my entire initramfs proposal included it. I want to know what William had _against_ the mounting /var in my proposal, because that is what his statement implied. -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85
Re: [gentoo-dev] /usr vs. initramfs redux
On Wed, Aug 10, 2011 at 08:02:44PM +, Robin H. Johnson wrote: On Wed, Aug 10, 2011 at 11:49:38AM -0500, William Hubbs wrote: I am concerned about /var being included in this because of the potential of filling up the root partition. Err, I don't follow. How does mounting /var fill up the root partition? Sorry, I should have been more clear here. Mounting /var doesn't fill up the root partition, but if you don't want to use the initramfs, this means that /var must also exist on the root partition, which can create more of a concern for filling the root partition than putting /usr on the root partition creates. William pgpYfi4TWQbkR.pgp Description: PGP signature
[gentoo-dev] The fun of being a PDEPEND
I've intermittently spent my last two days trying to figure out a weird bug on Entropy dependency resolution algorithm (which is actually just a simple topological sorting out of a digraph) due to an user reporting me a problem occurring during app-office/libreoffice pkg_setup phase. The problem is actually two problems, but anyways, to make it short (since it's not the topic here), bug #206024 is also a reason why I've been hit by all this mess. Entropy always tried to strictly follow PMS (bugs apart). Given the same document, about PDEPEND it says something like this: there is no guarantee that a PDEPEND gets installed at a certain, specified point during the schedule, if not specifically listed as RDEPEND by some package. The problem here is that Portage enforces the same rule by trying to schedule the PDEPEND as soon as possible, which leads ebuild writers to think to have gotten the deps order right. In simple words, it doesn't seem that Portage itself follows PMS or PMS is detailed enough. Try to ask your fellow developers this question: what is a PDEPEND? And you will get several different answers. The fact is, at least among us, it's still unclear what a PDEPEND is and how it behaves, also given the fact that other PMs strictly following the specifications end up generating wrong merge schedules. There are two main interpretations of what a PDEPEND is: 1. a way to fix circular dependecies (actually, it's wrong because there is no guarantee on the scheduling) 2. a way to have some handy packages being pulled in at some point (audacious plugins?) Who is this poor little PDEPEND? I think it's time to take action and fix the gray area around PDEPENDs, or at least clarify the fact to us developers. -- Fabio Erculiani
Re: [gentoo-dev] /usr vs. initramfs redux
Robin H. Johnson wrote: On Wed, Aug 10, 2011 at 03:47:18PM -0500, Dale wrote: On Wed, Aug 10, 2011 at 11:49:38AM -0500, William Hubbs wrote: I am concerned about /var being included in this because of the potential of filling up the root partition. Err, I don't follow. How does mounting /var fill up the root partition? If you take /var off its own partition and put it on /, then it will fill up / instead of /var. Filling up /var, not the end of the world. Filling up / is a bad thing. [snip] That is clear, but entirely irrelevant to my question. I _explicitly_ support /var on a partition, that's why my entire initramfs proposal included it. I want to know what William had _against_ the mounting /var in my proposal, because that is what his statement implied. For the record, I think /usr should work on a separate partition as well. One reason, I would like to use LVM on all but my / file system. This is something I been fiddling with for a while. Thing is, if /usr has to be on / then there is no point in me using LVM at all. I don't want / on a LVM because that requires some sort of init* to work. That is what I am trying to avoid. My opinion, this is going to lead to one heck of a mess. If it is coming from upstream, which it appears to be, then there needs to be someone to point the finger at. I read somewhere it is because of Fedora so that helps some. It's still going to be a mess. My gut sees it coming. I can already see where it is going to alter my plans hugely and I'm a desktop user. I can't imagine a server or some complicated setup. That is the ones I feel sorry for the most. If they are not using some init* thing already, they appear to be needing one soon. It's just one more thing to have to deal with and worry about breaking. Just my $0.02 worth and that ain't much. ;-) Dale :-) :-)
Re: [gentoo-dev] /usr vs. initramfs redux
On Wed, Aug 10, 2011 at 04:42:04PM -0500, Dale wrote: For the record, I think /usr should work on a separate partition as well. You're entirely missing the point of this thread. One reason, I would like to use LVM on all but my / file system. This is something I been fiddling with for a while. Thing is, if /usr has to be on / then there is no point in me using LVM at all. I don't want / on a LVM because that requires some sort of init* to work. That is what I am trying to avoid. The final solution in this thread: TL;DR version: If your /usr is NOT on /, you MUST use an initramfs. More detailed: 1. If you want /usr or /var on separate partitions (not LVM or anything elsewhere userspace action is required to make the block devices usable), then the minimal initramfs (or something more capable) MUST be used so that udev is happy. 2. If your /usr, /var, root etc block devices require userspace action (eg LVM, MD, crypto, firmware etc). You MUST use genkernel, dracut or some other initramfs of your own creation. The proposed minimal initramfs WILL NOT handle these situations. My opinion, this is going to lead to one heck of a mess. If it is coming from upstream, Yes, it's upstream, and their reasons are fairly valid: avoid circular dependencies in startup. -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85
Re: [gentoo-dev] /usr vs. initramfs redux
On Wed, Aug 10, 2011 at 03:57:30PM -0500, William Hubbs wrote: Sorry, I should have been more clear here. Mounting /var doesn't fill up the root partition, but if you don't want to use the initramfs, this means that /var must also exist on the root partition, which can create more of a concern for filling the root partition than putting /usr on the root partition creates. That's a problem for the users, not the initramfs. The initramfs supports /usr, /var and anything else as noted. Having /var on / is a perfectly valid choice for certain situations. The problem of filling up / is PEBKAC primarily, and can happen equally for / (think /root), /usr on /, /var on /. -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85
Re: [gentoo-dev] /usr vs. initramfs redux
Robin H. Johnson wrote: The final solution in this thread: TL;DR version: If your /usr is NOT on /, you MUST use an initramfs. More detailed: 1. If you want /usr or /var on separate partitions (not LVM or anything elsewhere userspace action is required to make the block devices usable), then the minimal initramfs (or something more capable) MUST be used so that udev is happy. 2. If your /usr, /var, root etc block devices require userspace action (eg LVM, MD, crypto, firmware etc). You MUST use genkernel, dracut or some other initramfs of your own creation. The proposed minimal initramfs WILL NOT handle these situations. The need of init* is just what I want to avoid. Seeing how this is coming, I'm glad I didn't get /usr, /var set up on LVM just to find out I got to put it back like it was before I put in all the effort to do it. Pardon me for saying this, this is a crap sandwich. Whoever came up with this should have to eat it. I hope all the people this messes up has his/her email addy. Dale :-) :-)
Re: [gentoo-dev] /usr vs. initramfs redux
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10-08-2011 21:56, Robin H. Johnson wrote: On Wed, Aug 10, 2011 at 03:57:30PM -0500, William Hubbs wrote: Sorry, I should have been more clear here. Mounting /var doesn't fill up the root partition, but if you don't want to use the initramfs, this means that /var must also exist on the root partition, which can create more of a concern for filling the root partition than putting /usr on the root partition creates. That's a problem for the users, not the initramfs. The initramfs supports /usr, /var and anything else as noted. Having /var on / is a perfectly valid choice for certain situations. The problem of filling up / is PEBKAC primarily, and can happen equally for / (think /root), /usr on /, /var on /. True, but it's also far more likely to happen when you have /usr and /var on / than otherwise. - -- Regards, Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org Gentoo- forums / Userrel / Devrel / KDE / Elections / RelEng -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJOQxMdAAoJEC8ZTXQF1qEPBKoQAI5FBt/rDaFSWA5ln6tmDNOt HhLq54dirdaXWSdHUp6C+vmSNcAC/QPmPlB8RA/bwXQ2aRlO0m4Jc6XPS3NTdT0H TEgqBQ+3NtZ3mRyTHv+E2YtDanemZIQ5rrpl0QuvMfeODUOM3zNdTosV6/37tmo+ 9clXHGzauPqWKpUvXxHc9Ic7OSA9ROXy1vq8wvTzvQWsg2sz7ML6pU7yAE5niC78 FlFgZyG2aZ0S+oBt88aSEkDEwU6aDlgQbLwxT5rN61QtE8wvV5hx5h7k74iJwkaJ 89vUbcgtmdMNFVYcXpIprlqkYWKr68uBxqsdSy2z+uX6d6E90G8mQs8qF9cHryFY YuA9WSXn4rtElsTkdrdA9yEqEwGXSeiD9oohn8wHwcVYNKWYKVPiRzeCxyAVOSVy dUqCRh5ZvTVuyD7wvVY1rVihCRLdSSOTYkUknOWexPs/PqvWmwDlhsEH79vVZeL2 pxnO5umvLKn17FL/jOimS2djua1b83elX99nqjdfZLTqT/DCeZ699YOD2Hc1Dd0O AtYmDzbJSNnjKoFVU8SGX4NspsGdilBFKCa5Gj6MUXqHgjHcMK23HpBcl76jIgeX tqK+ooJYsd0p/hwCV3gJqaUQvtvU3r05qfU7Qjzg3PAif0Heu4wrjKG056UkUIFb t1HYMphiA6ITXnSLVl7o =EcGc -END PGP SIGNATURE-
Re: [gentoo-dev] The fun of being a PDEPEND
On 08/10/2011 02:14 PM, Fabio Erculiani wrote: The problem here is that Portage enforces the same rule by trying to schedule the PDEPEND as soon as possible This behavior was introduced in order to solve bug 180045 [1]. We can accomplish similar results to the ASAP (as soon as possible) behavior in cases like this, if we create a virtual/meta-package that pulls in the circularly dependent packages. We also havo to update the reverse dependencies to refer to the virtual/meta-package. So, the ASAP behavior is really just a convenience so that ebuild maintainers don't have to go to the trouble of creating a virtual and updating all the reverse dependencies. [1] http://bugs.gentoo.org/show_bug.cgi?id=180045 -- Thanks, Zac
Re: [gentoo-dev] [RFC] /etc/resolv.conf symlink through net-dns/resolvconf-symlink
On Wednesday, August 10, 2011 05:55:19 Michał Górny wrote: I'm attaching a net-dns/resolvconf-symlink ebuild which replaces /etc/resolv.conf with a symlink to a runtime-writable location when installed. That package could be added to PDEPEND of packages like net-misc/networkmanager or net-dns/openresolv. sounds like useless layer. why not just merge it into openresolv itself ? -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] new virtual/yacc
On Sunday, August 07, 2011 19:21:15 Mike Frysinger wrote: now that yacc is no longer part of system, and we have multiple providers of yacc, we need a virtual. so unless there are any complaints, i'll be adding virtual/yacc which has || ( sys-devel/bison dev-util/yacc ). implemented and added/replaced in a bunch of packages -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] new virtual/yacc
On Sunday, August 07, 2011 23:32:09 Matt Turner wrote: On Sun, Aug 7, 2011 at 11:21 PM, Mike Frysinger vap...@gentoo.org wrote: now that yacc is no longer part of system, and we have multiple providers of yacc, we need a virtual. so unless there are any complaints, i'll be adding virtual/yacc which has || ( sys-devel/bison dev-util/yacc ). once that settles, i'll probably relocate bison to dev-util. Might also be worth looking at https://bugs.gentoo.org/show_bug.cgi?id=90089 at the same time. i'm not a big fan of eselect. but considering we have more than just two implementations, it's probably better than what we have atm. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] The fun of being a PDEPEND
On Thu, Aug 11, 2011 at 1:31 AM, Zac Medico zmed...@gentoo.org wrote: On 08/10/2011 02:14 PM, Fabio Erculiani wrote: The problem here is that Portage enforces the same rule by trying to schedule the PDEPEND as soon as possible This behavior was introduced in order to solve bug 180045 [1]. We can accomplish similar results to the ASAP (as soon as possible) behavior in cases like this, if we create a virtual/meta-package that pulls in the circularly dependent packages. We also havo to update the reverse dependencies to refer to the virtual/meta-package. In case of dev-java/jdom and dev-java/jdom-jaxen my idea was to create virtual/jdom (having it to pull in both deps in RDEPEND) and update the reverse dependencies. Waiting to hear back from Java herd (Caster, actually). OTOH, I think that the gray area should be cleared out by clearly stating what is legal or not in an updated EAPI. Isn't that reasonable? So, the ASAP behavior is really just a convenience so that ebuild maintainers don't have to go to the trouble of creating a virtual and updating all the reverse dependencies. [1] http://bugs.gentoo.org/show_bug.cgi?id=180045 -- Thanks, Zac -- Fabio Erculiani
Re: [gentoo-dev] The fun of being a PDEPEND
On Wed, 10 Aug 2011 23:14:22 +0200 Fabio Erculiani lx...@gentoo.org wrote: I've intermittently spent my last two days trying to figure out a weird bug on Entropy dependency resolution algorithm (which is actually just a simple topological sorting out of a digraph) You can't use a naive topological sort to do dependency resolution. RDEPEND-RDEPEND cycles are legal and common. Entropy always tried to strictly follow PMS (bugs apart). Given the same document, about PDEPEND it says something like this: there is no guarantee that a PDEPEND gets installed at a certain, specified point during the schedule, if not specifically listed as RDEPEND by some package. The problem here is that Portage enforces the same rule by trying to schedule the PDEPEND as soon as possible, which leads ebuild writers to think to have gotten the deps order right. In simple words, it doesn't seem that Portage itself follows PMS or PMS is detailed enough. Portage *tries*. There's no guarantee that it will succeed. If you need a particular ordering, you can't use PDEPEND. If something's there only because of a PDEPEND, there are absolutely no guarantees whatsoever as to when it will get resolved; PDEPEND imposes absolutely no reliable conditions upon ordering. Any ebuild assuming otherwise should be fixed. Purely as a quality of implementation issue, scheduling a PDEPEND reasonably soon after (or even before) the package requiring it may be a good idea, simply because users may get confused if when they try to install a bunch of things and one of those things gets installed long before related packages. But you can't rely upon that happening. (Incidentally, one could also argue that package manglers should always try to come up with the most perverse legal ordering possible for any situation. That way bugs will be identified much more quickly. Part of the problem with Portage is that it has so many tricks and so little error checking that broken things quite often appear to work.) -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] /usr vs. initramfs redux
On 2011-08-11 12:56 AM, Robin H. Johnson wrote: The problem of filling up / is PEBKAC primarily, and can happen equally for / (think /root), /usr on /, /var on /. This does not match with my experience. Over the years, I have seen /var filling up several times on servers, but not /. Please be careful with where you are going with this. As a side note, I do admire BSD now and then. Simplicity is good. -- Eray Aslan e...@gentoo.org signature.asc Description: OpenPGP digital signature
