Re: [gentoo-dev] POSIX shell and portable
On Tue, 06 Nov 2007 07:40:20 + Roy Marples [EMAIL PROTECTED] wrote: On Tue, 2007-11-06 at 07:12 +, Ciaran McCreesh wrote: Except it won't, because ebuilds require bash regardless of which package manager is being used. If you want to change that you'll have to rewrite the entire tree. Az once said near enough the same thing about baselayout. And that's your view, your entitled to it, but it is not my view. Change a little bit here, a little bit there. Slowly does it. It's not a view. It's a simple fact. Yes, I know that a fair chunk of the tree will need a re-write, just in the same way that the init scripts got a re-write. It will take time, it will not happen magically over night. To think overwise is foolish :) How many lines of code are in baselayout? How many in the tree? Pushing for non-bash for ebuilds is pointless. The cost of using bash is tiny; the cost of not using bash is huge. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] POSIX shell and portable
On Tue, 2007-11-06 at 08:03 +, Ciaran McCreesh wrote:
On Tue, 06 Nov 2007 07:40:20 +
Roy Marples [EMAIL PROTECTED] wrote:
On Tue, 2007-11-06 at 07:12 +, Ciaran McCreesh wrote:
Except it won't, because ebuilds require bash regardless of which
package manager is being used. If you want to change that you'll
have to rewrite the entire tree.
Az once said near enough the same thing about baselayout. And that's
your view, your entitled to it, but it is not my view. Change a little
bit here, a little bit there. Slowly does it.
It's not a view. It's a simple fact.
It's my considered opinion that it's a view.
You are free to call it what you like.
Yes, I know that a fair chunk of the tree will need a re-write, just
in the same way that the init scripts got a re-write. It will take
time, it will not happen magically over night. To think overwise is
foolish :)
How many lines of code are in baselayout? How many in the tree?
Pushing for non-bash for ebuilds is pointless. The cost of using bash is
tiny; the cost of not using bash is huge.
Size of baselayout compared to the tree is small vs huge. But unlike
baselayout, the ebuilds themselves should be relatively easy as they
don't normally use bash specific features [1]. The real work is in the
eclasses which make extensive use of bash specific features, such as
arrays. A quick look at the dir shows that there's probably a similar
number of eclasses to the number of init scripts installed by ebuilds.
[1] The one expection being ${var//foo/var} which is used a fair bit. It
could also be argued that versionator should be used more which oddly
enough should also reduce the use of this bashism.
Thanks
Roy
--
[EMAIL PROTECTED] mailing list
Re: [gentoo-dev] POSIX shell and portable
On Mon, 2007-11-05 at 23:18 +, Roy Marples wrote:
On Mon, 2007-11-05 at 16:21 -0400, Mike Frysinger wrote:
we want the installed environment to be portable, not the build
environment.
i do not see any benefit from forcing the build environment to be pure
POSIX
compliant and i see many many detrimental problems.
Oh I don't know. Imagine how cool it would be for starting a new port.
1) Install PM
2) Wang on a portage tree
3) emerge ready to go
Obviously it's not quite that simple as portage requires python and
pkgcore require python, paludis requires tr1-whatever libs - but that's
the restriction of the PM used. Maybe one day Gentoo will have a PM that
doesn't require any of that and is just written in C and sh, using POSIX
libc where it can.
But enough pipe dreaming :)
Stop dreaming: Some very rudimentary thing like this already exists:
To bootstrap an alt/prefix instance on AIX, HPUX, whatever-unix-without-
sufficient-GNU-userland, we're using some prefix-launcher[1].
This simply is a package fetcher/patcher/builder/installer, where a
single package is defined by some .build-script, which is written in
plain bourne shell. You might (should) find some gentoo ideas if you
look inside it ;)
Now to install {python, bash, (prefix-)portage, wget, patch, diffutils,
findutils, gcc, etc.} one single command[2] (think emerge system) does
it all, just requiring GNU make, /bin/sh being bourne shell, some ansi-c
compiler, some (non-GNU) tar, gunzip, (non-GNU) sed, (non-GNU) whatever.
So the only non-native (not installed by default) thing required is GNU
make, which is available as binary package without any dependencies for
each unix I've seen.
[1] http://sourceforge.net/projects/prefix-launcher/
[2] http://prefix-launcher.wiki.sourceforge.net/
/haubi/
--
Michael Haubenwallner
Gentoo on a different level
--
[EMAIL PROTECTED] mailing list
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in sys-apps/paludis: ChangeLog paludis-0.26.0_alpha3.ebuild
On 05/11/2007, Donnie Berkholz [EMAIL PROTECTED] wrote: Shouldn't need to create a user twice, and that quoting makes this a bit harder to read than it needs to be. Since which version of portage it's handled correctly? P.S. my $EDITOR shows quoted strings nicely. -- Best regards, Piotr Jaroszyński
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in sys-apps/paludis: ChangeLog paludis-0.26.0_alpha3.ebuild
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Piotr Jaroszyński wrote: On 05/11/2007, Donnie Berkholz [EMAIL PROTECTED] wrote: Shouldn't need to create a user twice, and that quoting makes this a bit harder to read than it needs to be. Since which version of portage it's handled correctly? The setup phase appears to run for binary packages in portage-2.0.51.22 at least, and the current tree is probably unusable for anyone who still has an older version of portage. Zac -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.7 (GNU/Linux) iD8DBQFHMDsJ/ejvha5XGaMRAlKVAJ0W7cToOWACNVvtrWF+yZpW/hATagCfbBv2 WsaTFQ4a/I/8JHVHhFlf3+s= =lCTB -END PGP SIGNATURE- -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: More general interface to use flags
Alec Warner wrote:
On 11/4/07, Steve Long [EMAIL PROTECTED] wrote:
One minor thing; -n is the default test, so:
[[ $1 ]] is the same as [[ -n $1 ]]
and:
[[ ! $1 ]] is the same as [[ -z $1 ]]
''help test'' is very revealing, for those who haven't read it. ;-)
Code Clarity over shortcuts. Use the explicit version.
There's nothing unclear about [[ $1 ]] IMO. But whatever floats
your ${boat} ;)
--
[EMAIL PROTECTED] mailing list
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-db/monetdb: ChangeLog metadata.xml monetdb-4.20.0.ebuild monetdb-5.2.0.ebuild monetdb-4.10.2.ebuild monetdb-4.12.0.ebuild
On Tue, Nov 06, 2007 at 10:44:07AM +, Fabian Groffen (grobian) wrote: Index: monetdb-4.20.0.ebuild ... DEPEND=dev-libs/libpcre dev-libs/openssl sys-libs/readline dev-libs/libxml2 java? ( dev-java/ant =virtual/jdk-1.5 ) boehmgc? ( dev-libs/boehm-gc ) =dev-db/monetdb-5 Why does monetdb-4.20.0 depend on =dev-db/monetdb-5*? Despite the SLOT=4 and SLOT=5, this strikes me as odd. -- Robin Hugh Johnson Gentoo Linux Developer Infra Guy E-Mail : [EMAIL PROTECTED] GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 pgpkhXmADYXMH.pgp Description: PGP signature
[gentoo-dev] Re: USE flag transition: tetex and latex
Alexis Ballier [EMAIL PROTECTED]: What are we going to do with the global tetex USE flag? app-text/tetex is deprecated in favour of TeXLive which is still hard masked but will be the default TeX distribution in the future. Rename it to tex as TeXLive is based on teTeX? And what about USE=latex? Use a generic tex for it, too? I had been thinking about it and am not sure what would be the best option: After some more calm minutes thinking about it: Some packages use the tetex useflag to enable some latex support, in which case a latex useflag should be fine. (e.g. doxygen is the first one I found that seems to be in that case) Agree. Some others use it to enable kpathsea support, where tetex is the historical distribution that provides it for us. From quickly digging into lcdf-typetools code for ex., it seems it is used there to locate files and update the kpathsea files so that other apps using kpathsea will see the changes it has made. That way it integrates with a tetex-alike distribution. So, imho, in that case a kpathsea useflag would make more sense; but I doubt such a useflag name will speak by itself. Yes, we should introduce tex, latex and kpathsea USE flags. Anyone? V-Li -- Christian Faulhammer, Gentoo Lisp project URL:http://www.gentoo.org/proj/en/lisp/, #gentoo-lisp on FreeNode URL:http://www.faulhammer.org/ signature.asc Description: PGP signature
[gentoo-dev] Re: USE flag transition: tetex and latex
Tobias Klausmann [EMAIL PROTECTED]: On Tue, 06 Nov 2007, Christian Faulhammer wrote: tetex-alike distribution. So, imho, in that case a kpathsea useflag would make more sense; but I doubt such a useflag name will speak by itself. Yes, we should introduce tex, latex and kpathsea USE flags. Anyone? As long as the description of the USE flag (such as by euse -i) is usefule (and *not* the equally omnipresentand useless foo - enables foo support), I see no trouble in using it. In this case I'd go for: kpathsea - Enable (La)TeX integration. Which I don't consider as correct: enable integration with kpathsea search library (TeX related) IMHO, it'd better be Support X11 DGA video output using the vidix interface Right, we have too many bad descriptions. Maybe a project for you to prepare a patch for use*.desc? :) V-Li -- Christian Faulhammer, Gentoo Lisp project URL:http://www.gentoo.org/proj/en/lisp/, #gentoo-lisp on FreeNode URL:http://www.faulhammer.org/ signature.asc Description: PGP signature
Re: [gentoo-dev] Re: USE flag transition: tetex and latex
Hi!
On Tue, 06 Nov 2007, Christian Faulhammer wrote:
tetex-alike distribution. So, imho, in that case a kpathsea useflag
would make more sense; but I doubt such a useflag name will speak by
itself.
Yes, we should introduce tex, latex and kpathsea USE flags. Anyone?
As long as the description of the USE flag (such as by euse -i)
is usefule (and *not* the equally omnipresentand useless foo -
enables foo support), I see no trouble in using it.
In this case I'd go for:
kpathsea - Enable (La)TeX integration.
I do understand that sometimes a given USE flags description
can't be unified. USE=foo might enable very different things in
different packages. But then, global USE flags are the only once
where this is a concern.
For example, take mplayer's (local) USE flag vidix. euse -i isn't
exactly helpful: Support for vidix video output
IMHO, it'd better be Support X11 DGA video output using the
vidix interface
One might argue that I should know the stuff I want but what if
I'd want the support for foo if I only knew about it?
Also, my (arguably not very good) example illustrates how extra
keywords might help the user find out what exactly vidix is using
Google.
Regards,
Tobias
PS: Yes, I've read the recend mp3/mp3{de,en}code discussuion,
same problem, actually.
--
In the future, everyone will be anonymous for 15 minutes.
--
[EMAIL PROTECTED] mailing list
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in profiles/updates: 4Q-2007
Hanno Boeck (hanno) [EMAIL PROTECTED] said: hanno 07/11/06 01:01:35 Modified: 4Q-2007 Log: move beryl packages to their corresponding compiz fusion packages Revision ChangesPath 1.10 profiles/updates/4Q-2007 file : http://sources.gentoo.org/viewcvs.py/gentoo-x86/profiles/updates/4Q-2007?rev=1.10view=markup plain: http://sources.gentoo.org/viewcvs.py/gentoo-x86/profiles/updates/4Q-2007?rev=1.10content-type=text/plain diff : http://sources.gentoo.org/viewcvs.py/gentoo-x86/profiles/updates/4Q-2007?r1=1.9r2=1.10 Index: 4Q-2007 === RCS file: /var/cvsroot/gentoo-x86/profiles/updates/4Q-2007,v retrieving revision 1.9 retrieving revision 1.10 diff -u -r1.9 -r1.10 --- 4Q-2007 3 Nov 2007 15:35:36 - 1.9 +++ 4Q-2007 6 Nov 2007 01:01:35 - 1.10 @@ -8,3 +8,10 @@ move x11-apps/compiz-settings x11-apps/ccsm move x11-plugins/compiz-extra x11-plugins/compiz-fusion-plugins-main slotmove =app-emulation/emul-linux-x86-java-1.4* 1.4.2 1.4 +move x11-wm/beryl x11-wm/compiz-fusion +move x11-wm/beryl-core x11-wm/compiz +move x11-plugins/beryl-plugins x11-plugins/compiz-fusion-plugins-main +move x11-plugins/beryl-dbus x11-plugins/compiz-fusion-plugins-extra +move x11-misc/beryl-settings-bindings x11-libs/compizconfig-python +move x11-misc/beryl-settings x11-libs/libcompizconfig +move x11-misc/beryl-manager x11-apps/ccsm Just to get a wider audience involved in this...this just seems wrong to do. There is a QA bug open about it as well: https://bugs.gentoo.org/show_bug.cgi?id=198248 What are other people's feelings on using package moves to forcibly migrate people like this? It also sounds like this wasn't announced at all and the packages just left the tree. -- Mark Loeser email - mark AT halcy0n DOT com web - http://www.halcy0n.com pgpXm4ASAsbex.pgp Description: PGP signature
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in profiles/updates: 4Q-2007
Mark Loeser wrote: Hanno Boeck (hanno) [EMAIL PROTECTED] said: hanno 07/11/06 01:01:35 Modified: 4Q-2007 Log: move beryl packages to their corresponding compiz fusion packages Revision ChangesPath 1.10 profiles/updates/4Q-2007 file : http://sources.gentoo.org/viewcvs.py/gentoo-x86/profiles/updates/4Q-2007?rev=1.10view=markup plain: http://sources.gentoo.org/viewcvs.py/gentoo-x86/profiles/updates/4Q-2007?rev=1.10content-type=text/plain diff : http://sources.gentoo.org/viewcvs.py/gentoo-x86/profiles/updates/4Q-2007?r1=1.9r2=1.10 Index: 4Q-2007 === RCS file: /var/cvsroot/gentoo-x86/profiles/updates/4Q-2007,v retrieving revision 1.9 retrieving revision 1.10 diff -u -r1.9 -r1.10 --- 4Q-2007 3 Nov 2007 15:35:36 - 1.9 +++ 4Q-2007 6 Nov 2007 01:01:35 - 1.10 @@ -8,3 +8,10 @@ move x11-apps/compiz-settings x11-apps/ccsm move x11-plugins/compiz-extra x11-plugins/compiz-fusion-plugins-main slotmove =app-emulation/emul-linux-x86-java-1.4* 1.4.2 1.4 +move x11-wm/beryl x11-wm/compiz-fusion +move x11-wm/beryl-core x11-wm/compiz +move x11-plugins/beryl-plugins x11-plugins/compiz-fusion-plugins-main +move x11-plugins/beryl-dbus x11-plugins/compiz-fusion-plugins-extra +move x11-misc/beryl-settings-bindings x11-libs/compizconfig-python +move x11-misc/beryl-settings x11-libs/libcompizconfig +move x11-misc/beryl-manager x11-apps/ccsm Just to get a wider audience involved in this...this just seems wrong to do. There is a QA bug open about it as well: https://bugs.gentoo.org/show_bug.cgi?id=198248 What are other people's feelings on using package moves to forcibly migrate people like this? It also sounds like this wasn't announced at all and the packages just left the tree. Except the packages referenced are simply the same upstream project just renamed... so it is correct. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: USE flag transition: tetex and latex
Hi! On Tue, 06 Nov 2007, Christian Faulhammer wrote: Tobias Klausmann [EMAIL PROTECTED]: On Tue, 06 Nov 2007, Christian Faulhammer wrote: tetex-alike distribution. So, imho, in that case a kpathsea useflag would make more sense; but I doubt such a useflag name will speak by itself. Yes, we should introduce tex, latex and kpathsea USE flags. Anyone? As long as the description of the USE flag (such as by euse -i) is usefule (and *not* the equally omnipresentand useless foo - enables foo support), I see no trouble in using it. In this case I'd go for: kpathsea - Enable (La)TeX integration. Which I don't consider as correct: enable integration with kpathsea search library (TeX related) IMHO, it'd better be Support X11 DGA video output using the vidix interface Right, we have too many bad descriptions. Maybe a project for you to prepare a patch for use*.desc? :) Actually, I might consider it. Unfortunately, I tried to cut off my finger last sunday and as such I'm typing-impaired for now. At least I got sick leave until Friday :-/ And two nasty tetanus shots :-( cue more whining, I'm too lazy to type Anyway, I'm considering your offer :) Regards, Tobias -- In the future, everyone will be anonymous for 15 minutes. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-db/monetdb: ChangeLog metadata.xml monetdb-4.20.0.ebuild monetdb-5.2.0.ebuild monetdb-4.10.2.ebuild monetdb-4.12.0.ebuild
On 06-11-2007 04:03:32 -0800, Robin H. Johnson wrote: On Tue, Nov 06, 2007 at 10:44:07AM +, Fabian Groffen (grobian) wrote: Index: monetdb-4.20.0.ebuild ... DEPEND=dev-libs/libpcre dev-libs/openssl sys-libs/readline dev-libs/libxml2 java? ( dev-java/ant =virtual/jdk-1.5 ) boehmgc? ( dev-libs/boehm-gc ) =dev-db/monetdb-5 Why does monetdb-4.20.0 depend on =dev-db/monetdb-5*? Despite the SLOT=4 and SLOT=5, this strikes me as odd. It is odd, but an effect from MonetDB v4 being deprecated. -- Fabian Groffen Gentoo on a different level -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in profiles/updates: 4Q-2007
Mark Loeser kirjoitti: What are other people's feelings on using package moves to forcibly migrate people like this? It also sounds like this wasn't announced at all and the packages just left the tree. Using package moves like this causes for example the following problem. If you now depend on just x11-libs/libcompizconfig you really can't be sure that the user has libcompizconfig files on his system because it's enough that the files from beryl-settings are there. As such building stuff will fail. Stuff does work as long as =x11-libs/libcompizconfig-0.6. for example is used everywhere. Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in profiles/updates: 4Q-2007
On Tue, 6 Nov 2007 11:15:12 -0500 Mark Loeser [EMAIL PROTECTED] wrote: Just to get a wider audience involved in this...this just seems wrong to do. There is a QA bug open about it as well: https://bugs.gentoo.org/show_bug.cgi?id=198248 What are other people's feelings on using package moves to forcibly migrate people like this? It also sounds like this wasn't announced at all and the packages just left the tree. A package move via update file is simply an extension of a mv command. If you also had to edit the ebuild a package move is generally not the right thing to do. Remember that a package move applies to all versions of a package, and upstream name changes are generally tied to specific versions. Marius -- [EMAIL PROTECTED] mailing list
[gentoo-dev] EAPI feature suggestion: OBSOLETES (was: gentoo-x86 commit in profiles/updates: 4Q-2007)
Whether or not 'move' was the correct action in the recent compiz example, perhaps we need to consider that some times one package does actually make another obsolete. The correct thing for the PM to do is to first uninstall the obsolete package, then install the new one. Now, it has been my experience that blocking dependencies are currently used to imply this No, you have to remove cat/foo first before installing cat/bar instead situation. This is somewhat annoying for me when I want to upgrade a bunch of packages, but I have to manually uninstall a few blockers first before this is possible. This could be automated by the PM in those cases with some sort of thing like this in the cat/bar-1.0.ebuild: OBSOLETES=cat/foo Of course this would be a regular package atom (or list thereof), so it could be tied to specific versions of cat/foo. I suppose this could be seen as a special case of blocking deps which would automate a specific cat/bar is to be preferred over cat/foo However, I'm not exactly sure what you would do if you have pkg1 which depends on cat/foo and pkg2 which depends on cat/bar... -- Jim Ramsay Gentoo Developer (rox/fluxbox/gkrellm) signature.asc Description: PGP signature
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in sys-apps/paludis: ChangeLog paludis-0.26.0_alpha3.ebuild
On Tuesday 06 November 2007, Piotr Jaroszyński wrote: On 05/11/2007, Donnie Berkholz [EMAIL PROTECTED] wrote: Shouldn't need to create a user twice, and that quoting makes this a bit harder to read than it needs to be. Since which version of portage it's handled correctly? since when did it fail ... ive never heard of pkg_* funcs not being run properly -mike signature.asc Description: This is a digitally signed message part.
