Re: [gentoo-dev] RFC: an eclass to handle optional runtime depends
On 08/02/2011 11:29 AM, Ciaran McCreesh wrote: On Tue, 2 Aug 2011 20:18:17 +0200 Michał Górny mgo...@gentoo.org wrote: I think I prefer the second option (copying from Exherbo). A better integration with the package manager than USE flags should result in a better user experience. Are you willing to update and EAPI-bump all the eclasses? May I remind you that most of them don't even go beyond EAPI 0? Most of them shouldn't need to care about EAPI at all. For those that do, the only changes that should be necessary for an Exherbo-like SDEPEND solution are for packages that actually want to use it... If you also want to switch from *DEPEND to DEPENDENCIES (which would also allow a whole bunch of other long standing feature requests to be fulfilled) then it's still only slightly more work -- but last time I asked, adding new dependency classes or switching dependency syntax was in the too tricky to do in Portage boat. Nowadays, it's not too tricky to do in Portage. The code that translates *DEPEND into objects can easily be extended to translate something like DEPENDENCIES into similar objects. -- Thanks, Zac
[gentoo-dev] Re: RFC: Changing portage's unpack behavior for non-tar files compressed with gz|Z|z|bz2|bz|lzma|xz extensions
On 07/30/2011 01:42 PM, Zac Medico wrote:
Hi everyone,
We've found that portage's unpack behavior is inconsistent for non-tar
files compressed with gz|Z|z|bz2|bz|lzma|xz extensions [1]. Currently,
it emulates tools like gunzip and bunzip2, unpacking them to the
directory of the source file.
For consistency, we could make it unpack them to cwd instead. PMS
already specifies that the files should unpack to cwd, so this change
will bring portage and PMS into agreement. Hopefully it won't break too
many ebuilds, and we can always add compatibility code to ebuilds, like
this:
[[ ! -f ${x} ]] { mv ${x}.gz ./ || die mv failed; }
Is anyone opposed to making this change?
[1] http://bugs.gentoo.org/show_bug.cgi?id=376741
The PMS compliant unpack behavior is implemented in
sys-apps/portage-2.1.10.10.
It's unlikely to cause any problems, if any, since the most common
practice is to unpack source files that are already in the cwd. There
were only 2 packages in all of gentoo-x86 that needed to be fixed
because they unpacked files that weren't in the cwd:
http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/www-plugins/google-talkplugin/google-talkplugin-2.1.7.0.ebuild?view=log#rev1.3
http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/games-arcade/tuxpuck/tuxpuck-0.8.2-r1.ebuild?view=log#rev1.7
--
Thanks,
Zac
Re: [gentoo-dev] Re: POSIX capability in Gentoo
On Tue, 2 Aug 2011 17:29:29 -0700 Brian Harring ferri...@gmail.com wrote: On Tue, Aug 02, 2011 at 06:39:18PM +0100, Ciaran McCreesh wrote: On Tue, 02 Aug 2011 13:36:12 -0400 Jonathan Callen a...@gentoo.org wrote: That statement needs one more qualification: and doesn't use portage. Portage will (by default) remove files on uninstall even if they *do not* match the checksum recorded in the vdb. This implies that most people will *not* see any issues due to something other than the package manager modifying the files behind the package manager's back. Ugh, seriously? When did that happen? That's a massive change to how VDB is supposed to work. That's been in place a long while; pkgcore has done it from day one also. That's not a massive change to vdb behaviour either; file collisions aren't supposed to occur, as such ownership of the file is basically guranteed back to a single package. Throw in CONFIG_PROTECT for adjusting the behaviour, and you have a far more preferable norm than lets just leave a shit ton of .pyc/.pyo on the fs. It is a massive change, since if the feature is there then people don't feel bad about writing lousy pkg_ functions that leave a load of .pyc / .pyo files all over the place. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Delivery reports about your e-mail
On Wed, 03 Aug 2011 07:27:23 +0200 Francisco Blas Izquierdo Riera (klondike) klond...@gentoo.org wrote: El 03/08/11 06:57, Robin H. Johnson escribió: On Wed, Aug 03, 2011 at 04:13:19AM +0200, Francisco Blas Izquierdo Riera (klondike) wrote: Come on they can't be serious... this won't work against Gentoo devs, will it? It is concerning that the spammer used a valid list subscriber. Crunching all attachments for validation or moderating everything to catch this is a lot of work. What about using an antispam filter reference for moderation. A properly configured antispam system should have detected a mail like that one as, at least, a possible virus. A good moderation would be to require PGP signatures as well but I guess many devs still don't do that. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Delivery reports about your e-mail
On Wed, Aug 3, 2011 at 7:43 AM, Michał Górny mgo...@gentoo.org wrote: On Wed, 03 Aug 2011 07:27:23 +0200 Francisco Blas Izquierdo Riera (klondike) klond...@gentoo.org wrote: El 03/08/11 06:57, Robin H. Johnson escribió: On Wed, Aug 03, 2011 at 04:13:19AM +0200, Francisco Blas Izquierdo Riera (klondike) wrote: Come on they can't be serious... this won't work against Gentoo devs, will it? It is concerning that the spammer used a valid list subscriber. Crunching all attachments for validation or moderating everything to catch this is a lot of work. What about using an antispam filter reference for moderation. A properly configured antispam system should have detected a mail like that one as, at least, a possible virus. A good moderation would be to require PGP signatures as well but I guess many devs still don't do that. This list is public, so not just developers need keys, but anyone who posts would need to sign their mails, and then put their public key on a keyserver, and then somehow let the mail server know where the public key is. lolwut? PS: Get decent spam fitlers ;) -A -- Best regards, Michał Górny
[gentoo-dev] unison needs some love
Hello! Version in Gentoo: 2.32.52 Version upstream: 2.40.63 https://bugs.gentoo.org/show_bug.cgi?id=353282 The bug is old enough to justify a takeover to me, provided you act with resonable care. Sebastian
Re: [gentoo-dev] unison needs some love
On Wed, 03 Aug 2011 19:20:18 +0200 Sebastian Pipping sp...@gentoo.org wrote: Hello! Version in Gentoo: 2.32.52 Version upstream: 2.40.63 https://bugs.gentoo.org/show_bug.cgi?id=353282 The bug is old enough to justify a takeover to me, provided you act with resonable care. +1 I'm more or less alone in the ml herd (maintainer) and I don't use unison :( A. PS: bug age doesn't justify takeover usually, it's always better to ask before, but in this case you're right :)
Re: [gentoo-dev] unison needs some love
On 08/03/2011 07:37 PM, Alexis Ballier wrote: I'm more or less alone in the ml herd (maintainer) and I don't use unison :( While you mention the herd: how come this is herd=ml? Best, Sebastian
Re: [gentoo-dev] unison needs some love
On Wed, 03 Aug 2011 21:38:10 +0200 Sebastian Pipping sp...@gentoo.org wrote: On 08/03/2011 07:37 PM, Alexis Ballier wrote: I'm more or less alone in the ml herd (maintainer) and I don't use unison :( While you mention the herd: how come this is herd=ml? because it's written in ocaml
Re: [gentoo-dev] Re: POSIX capability in Gentoo
On Wed, Aug 03, 2011 at 12:34:21PM +0100, Ciaran McCreesh wrote: On Tue, 2 Aug 2011 17:29:29 -0700 Brian Harring ferri...@gmail.com wrote: That's not a massive change to vdb behaviour either; file collisions aren't supposed to occur, as such ownership of the file is basically guranteed back to a single package. Throw in CONFIG_PROTECT for adjusting the behaviour, and you have a far more preferable norm than lets just leave a shit ton of .pyc/.pyo on the fs. It is a massive change, since if the feature is there then people don't feel bad about writing lousy pkg_ functions that leave a load of .pyc / .pyo files all over the place. Quoting the good spec: The unmerge process removes an installed package's files. It is not covered in detail in this specification. Aka, ebuild's should be written to assume the files they install get wiped; there is *zero* mention of mtime, nor could any ebuild rely on it and be compliant. Background as to why we ever relied on mtime- it was a hack to work around a bad implementation in portage (treewalk function); it didn't actually know if it was replacing or what not, so mtime was what was relied on- afaik, that being the sole reason we shoved mtime into the vdb also. At least from the portage standpoint, shifting away from mtime reliance was on the radar since '05 and implemented at least initially by '06... exact date it was released from a stable branch I couldn't tell you, but it's been there a long while. ~brian
Re: [gentoo-dev] Re: POSIX capability in Gentoo
On Wed, 3 Aug 2011 14:26:56 -0700 Brian Harring ferri...@gmail.com wrote: Aka, ebuild's should be written to assume the files they install get wiped; there is *zero* mention of mtime, nor could any ebuild rely on it and be compliant. But as it's a FEATURE, they can't assume that at all. So either we spec VDB and the unmerge process, which gets horrible for all kinds of reasons, or ebuilds can't assume that things that have been modified get wiped. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: POSIX capability in Gentoo
On Wed, Aug 03, 2011 at 10:28:51PM +0100, Ciaran McCreesh wrote: On Wed, 3 Aug 2011 14:26:56 -0700 Brian Harring ferri...@gmail.com wrote: Aka, ebuild's should be written to assume the files they install get wiped; there is *zero* mention of mtime, nor could any ebuild rely on it and be compliant. But as it's a FEATURE, they can't assume that at all. It's outside the ebuild's area of concern (think seperation of concerns), just the same as INSTALL_MASK. The ebuild, per spec, should be written to assume it's wiped. If the user overrides portages make.globals setting FEATURES=unmerge-orphans it is on the *users* head to maintain the fallout, just the same as if they go and set INSTALL_MASK to do something special. So either we spec VDB and the unmerge process, which gets horrible for all kinds of reasons, or ebuilds can't assume that things that have been modified get wiped. This is getting more into the sky is falling territory. If you'd like to tighten the spec, go nuts, but there isn't anything to see here nor is there a real issue. This really is no different than INSTALL_MASK. ~brian
Re: [gentoo-dev] Warn users not to do separate /usr partition without proper initramfs in the handbook?
On Sat, 30 Jul 2011 10:27:27 +0300 Samuli Suominen ssuomi...@gentoo.org wrote: Since running separate /usr without mounting it from initramfs on top of / before init is and has been broken with udev for a long time now[1][2][3] [1] http://bugs.gentoo.org/show_bug.cgi?id=364235 [2] http://fedoraproject.org/wiki/Features/UsrMove#Move_all_to_.2Fusr [3] http://www.freedesktop.org/wiki/Software/systemd/separate-usr-is-broken Can we warn users about not doing the separate /usr mistake in the handbook? So, let's sum up a little. The most common argument against separate /usr requiring a proper initramfs is 'it works now, thus it's great'. That is practically understandable that people don't like to switch things upside down like that, especially when machines are not locally reachable. What's the exact differences between an initramfs and an early bootup setup in rootfs? As I see it: - initramfs is a small fs which is used for a short while on boot, to setup the system necessarily for the early bootup sequence, - while initial rootfs is a rather large piece of fs which is supposed to contain random stuff necessary for the early bootup to be able to proceed and mount the necessary remaining stuff before the actual bootup begins. And we're mostly stuck with it for the whole runtime. As I see it, I see no reason to keep forcing things like complete glibc, ncurses and the whole other lot of libraries for the early bootup if all needed is some kind of minimal 'mount' program (for instance). In the ol' days I tried building a NFS-shared system and the main problem was that some of early run tools relied heavily on the local system libs and files before they were replaced by NFS mounts. And I had to keep them in sync manually which is not the most comfortable thing. I don't see how trying to fit the best set of libs and files into rootfs can solve it. You either want for the system to be clean or weirdly split to support various possible configurations. And decide which are not 'weird enough' not to support. And really, most of the things about separate /usr are hacks which were introduced because the system was incapable of a proper rootfs. Read-only /usr should be read-only rootfs with writable mounts on top of it. NFS-mounted /usr should be the whole system part network-mounted (which would be easier if everything went into /usr rather than being split). -- Best regards, Michał Górny signature.asc Description: PGP signature
[gentoo-dev] Last rites: dev-libs/libots
# Matt Turner matts...@gentoo.org) (04 Aug 2011) # libots is only used by Compaq's C compiler, which was tree # cleaned years ago. Masked for removal in 30 days. dev-libs/libots
