Re: [gentoo-dev] [RFC] Portability eclass
On Friday 16 September 2005 17:42, Diego 'Flameeyes' Pettenò wrote: If we'll find other functions needed for portability's sake, they'll probably going to be there, too. Dropped the symcmd function, cleaned up the treecopy function (Martin, take a look at cp --parent, what treecopy does is just the same, if someone calls it with ${S}, it WILL create ${S} inside ${D}, but that's what they are asking for using it), added an eseq option, that would be used on enewuser and elsewhere were seq is used. This does not use ${USERLAND} to find out which command to use, as Darwin can have seq installed (and actually someone can have userland-gnu merged on *BSD and path changed), so it just look if it's able to find seq, otherwise use jot. If this is ok, I'll commit this tonight changing enewuser according to use it. -- Diego Flameeyes Pettenò Gentoo Developer - http://dev.gentoo.org/~flameeyes/ (Gentoo/FreeBSD, Video, Gentoo/AMD64, Sound, PAM) pgp2W2zocBBIr.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] Portability eclass
On Friday 16 September 2005 11:42 am, Diego 'Flameeyes' Pettenò wrote: the second one is a commodity function to symlink commands and manpages at once (as done by bsdtar and other packages). i dont see this being really useful ... either way, assuming the manpage is compressed with gzip (or compressed at all) is wrong -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] Portability eclass
On Fri, 2005-09-16 at 17:42 +0200, Diego 'Flameeyes' Pettenò wrote: If nobody finds problem in the attached eclass, I'm going to commit this tonight or tomorrow. The first function is a drop-in replacement for cp --parent (that doesn't work on BSD userland), the second one is a commodity function to symlink commands and manpages at once (as done by bsdtar and other packages). If we'll find other functions needed for portability's sake, they'll probably going to be there, too. I do not think its so urgent? Either way, we have elibs approved now, so how about waiting a while so that we do not have yet another elib candidate to port? Also, treecopy() will break if I do: treecopy ${S}/data ${D}/usr/share/foodata -- Martin Schlemmer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [RFC] Portability eclass
On Friday 16 September 2005 18:16, Martin Schlemmer wrote: I do not think its so urgent? Either way, we have elibs approved now, so how about waiting a while so that we do not have yet another elib candidate to port? There are at least two ebuilds in portage that uses cp --parente . It wasn't being a problem if it wasn't used. elib can be approved, but we're working on Gentoo/*BSD (and Gentoo/OSX) now, not 4 years from now (ok that was an exageration, but simplify what the problem is: it doesn't seem probable that a newer portage goes out working and ebuilds start using the new features in a little time. Remember that we had a bit of opposition also to have gcc using USE_EXPAND-ed variables, I can't figure what would happen also if tomorrow we find a portage with elib working :/ -- Diego Flameeyes Pettenò Gentoo Developer - http://dev.gentoo.org/~flameeyes/ (Gentoo/FreeBSD, Video, Gentoo/AMD64, Sound, PAM) pgpIQB0FsUuqM.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] Portability eclass
On Fri, 2005-09-16 at 18:33 +0200, Diego 'Flameeyes' Pettenò wrote: On Friday 16 September 2005 17:59, Mike Frysinger wrote: i dont see this being really useful ... either way, assuming the manpage is compressed with gzip (or compressed at all) is wrong Doesn't portage always gzip manpages? No, it can bzip2 them, also. -- Chris Gianelloni Release Engineering - Strategic Lead Games - Developer Gentoo Linux signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [RFC] Portability eclass
On Friday 16 September 2005 12:33 pm, Diego 'Flameeyes' Pettenò wrote: On Friday 16 September 2005 17:59, Mike Frysinger wrote: i dont see this being really useful ... either way, assuming the manpage is compressed with gzip (or compressed at all) is wrong Doesn't portage always gzip manpages? current stable does yes, but ive started adding customizable compression to trunk -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] Portability eclass
Diego 'Flameeyes' Pettenò wrote: On Friday 16 September 2005 19:28, Mike Frysinger wrote: current stable does yes, but ive started adding customizable compression to trunk Okay, then *that* is a problem :P Suggestion how to fix it? You are going to have to ask portage what it used via a PortageAPI call, I'd gather. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] Portability eclass
On Friday 16 September 2005 01:36 pm, Diego 'Flameeyes' Pettenò wrote: On Friday 16 September 2005 19:28, Mike Frysinger wrote: current stable does yes, but ive started adding customizable compression to trunk Okay, then *that* is a problem :P Suggestion how to fix it? simple, dont add the function but i guess if you insist on cruft, create the symlink w/out a compression extension and portage may fix it for you (or it may remove it, who knows) -mike -- gentoo-dev@gentoo.org mailing list