[gentoo-dev] Re: Ebuild limits?
Dave Nebinger posted <[EMAIL PROTECTED]>, excerpted below, on Mon, 03 Oct 2005 01:46:13 -0400: >> Wouldn't it be better to use the >> associated portage-provided packages? > > That's the goal - strip out the parts from their distribution that have > exiting components already within the portage tree (and already installed on > my system). Boils down to a couple of wars for the most part, plus scripts, > things like that. If you haven't looked at them yet (you may be well past this, it sounds like you are well farther along than I am in ebuilding experience -- I don't think I'd be tackling that job)... * Check out the split kde ebuilds (konqueror, kcontrol, etc, instead of kdebase, kmail, knode, the various handheld/PIM builds, instead of kdepim, etc) to see how an existing in-portage solution manages taking only part of the source and configuring/building based on already merged components from the rest of the source. * Check out the xorg-x11 builds, for a good example of a rather complex ebuild, broken down into logically digestible pieces, in the form of multiple functions within the ebuild. * Both of these use eclasses as well, but the kde ones especially should be instructive for their use of the kde eclasses to handle the various split functionality, if you decide to go with eclasses for part of it. Just because it might be of help... -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman in http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] grub reiser4
On 03/10/05, Mike Doty <[EMAIL PROTECTED]> wrote: > I'd prefer if the patch was left out for amd64 users, or included via a > use flag. reiser4 isn't yet stable or proven on amd64. A quick search found this quote: "The topic in channel #gentoo-amd64 on irc.freenode.net has said "Reiser4 is evil" for more than a year." However http://gentoo-wiki.com/HOWTO_AMD_64 and the forum threads it links to seem to suggest that people are successfully using reiser4 on amd64 with recent kernels? -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: user/group manipultaion feedback request.
Tres Melton posted <[EMAIL PROTECTED]>, excerpted below, on Mon, 03 Oct 2005 00:49:29 -0600: > However, this is going to take a couple of weeks to write entirely in > bash so that it is both portable and can be used on the most minimal of > systems. Imagine seeing /you/ here! =8^) Portability is good, but as I've been reading Diego "Flameeyes" various posts as he struggles to get Gentoo/FBSD up and running, and with Gentoo/Darwin and etc. in mind, I'm sure one of the requests is going to be making it full borne shell standard compatible, therefore, no "bash-isms". Likewise, keep in mind POSIX compatibility when making any sed/grep/file/etc calls. Don't assume the GNU versions. If you need the info, I believe most of the manpages specify where the GNU versions deviate from POSIX. I'm sure Flameeyes will be glad to help, as it'll mean less porting issues he and others need to worry about later. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman in http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] lights on internals
Brian Harring wrote:
>On Sun, Oct 02, 2005 at 11:07:13PM +0200, Francesco R wrote:
>
>
>>The ready to cut ebuild at the bottom print it's environment (variable
>>and functions) to a bunch of files into /var/tmp/fakebuild/.
>>May be useful for who want to have a look at "what" and "when" is
>>avaible during the various emerge phases (but not limited to).
>>print_env() {
>>local fakebuild_output_dir="/var/tmp/fakebuild"
>>mkdir -p "${fakebuild_output_dir}" || die
>>
>>[[ -z "${fakebuild_progr}" ]] && fakebuild_progr=100
>>fakebuild_progr=$(( $fakebuild_progr +1 ))
>>export fakebuild_progr
>>
>>local fakebuild_ext="${1}.${fakebuild_progr}"
>>
>># not sorting, break multiline vars
>>einfo "${fakebuild_output_dir}/env_${fakebuild_ext}"
>>env \
>>&> "${fakebuild_output_dir}/env_${fakebuild_ext}"
>>
>># Remove egrep and sort to see the source of every fx
>>einfo "${fakebuild_output_dir}/fxlist_${fakebuild_ext}"
>>typeset \
>>| egrep '^\b.* \(\)' \
>>| sort \
>>&> "${fakebuild_output_dir}/fxlist_${fakebuild_ext}"
>>}
>>
>>
>
>This won't work as you expect. Env is a binary, it only gets
>the exported env.
>
>
>
Got the point (maybe), "typeset" is a Bash built-in.
The first part of the "typeset" output command give the variable list
*and* it's different from the output of "env" binary.
The output is different in two ways, first the vars are differently
formatted, missing apices " ' " for example.
env also is missing all .bashrc defined vars (speaking of a normal
environment not of a portage/emerge one).
==> the "env" command should be replaced by
typeset &> tmpfile
tmpfile | grep -B1 "$(egrep "^\b.* \(\)" tmpfile | head -n 1)" |
head -n '-1'
(basically the output of typeset cutted at first function)
>Elaborate on the "what and when" bit also, since the env that's dumped
>to ebuild.sh varies depending on a lot of things.
>~harring
>
>
>
The environment is changing between the various predefined functions and
in the global scope of an ebuild, at the moment only for vars, not for
functions.
example of variable vars are:
SANDBOX_*
PORTAGE_RESTRICT
TMP
EBUILD_PHASE
TMPDIR
PWORKDIR
DISTCC_DIR
LD_PRELOAD
All variables that must stay readonly, or not readed at all, inside an
ebuild but may explain at the human that's writing one, what's happening
and when.
better ?
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: user/group manipultaion feedback request.
On Monday 03 October 2005 11:14, Duncan wrote: > Portability is good, but as I've been reading Diego "Flameeyes" various > posts as he struggles to get Gentoo/FBSD up and running, and with > Gentoo/Darwin and etc. in mind, I'm sure one of the requests is going to > be making it full borne shell standard compatible, therefore, no > "bash-isms". Actually, bash is fine, as long as you declare #!/bin/bash the script. Every Gentoo/ALT system should have bash installed as part of base system, as bash is what the ebuilds are written in. Having to make them bourne-compatible would be a great mess. But /bin/sh can be something different from bash, and be a minimal bourne-style shell, so it's important not to assume that /bin/sh == bash. > Likewise, keep in mind POSIX compatibility when making any > sed/grep/file/etc calls. Don't assume the GNU versions. If you need the > info, I believe most of the manpages specify where the GNU versions > deviate from POSIX. Also here the point is not to avoid GNU calls on every tool, is just to make sure that the tool called is actually GNU :) The insidious GNUisms are the ones relative, for example, to cp or mv, which are base system commands. But GNUisms in sed calls are usually safe as long as you make sure that you're calling GNU sed. Ebuilds sanitize this aliasing it to gsed, while eselect uses aliases that checks the right tool to use. You can give a look to http://www.gentoo.org/proj/en/gentoo-alt/maintnotes.xml#doc_chap2 to have a list of common problems with GNUisms. -- Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/ Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: user/group manipultaion feedback request.
On Mon, 2005-10-03 at 12:04 +0200, Diego 'Flameeyes' Pettenò wrote:
> On Monday 03 October 2005 11:14, Duncan wrote:
Hello Duncan.
> Actually, bash is fine, as long as you declare #!/bin/bash the script. Every
> Gentoo/ALT system should have bash installed as part of base system, as bash
> is what the ebuilds are written in.
Good as this is what I was working from. I've coded the parts that
extract and parse the information from the /etc/{passwd,group} files
already as well as reading and writing the config files and not found it
necessary to make any head, tail, sed, grep, awk, wing and a prayer
calls. :)As I said, I want to write this in bash itself as much as
possible for portability.
> > Likewise, keep in mind POSIX compatibility when making any
> > sed/grep/file/etc calls. Don't assume the GNU versions. If you need the
> > info, I believe most of the manpages specify where the GNU versions
> > deviate from POSIX.
> Also here the point is not to avoid GNU calls on every tool, is just to make
> sure that the tool called is actually GNU :)
> The insidious GNUisms are the ones relative, for example, to cp or mv, which
> are base system commands. But GNUisms in sed calls are usually safe as long
> as you make sure that you're calling GNU sed. Ebuilds sanitize this aliasing
> it to gsed, while eselect uses aliases that checks the right tool to use.
>
> You can give a look to
> http://www.gentoo.org/proj/en/gentoo-alt/maintnotes.xml#doc_chap2 to have a
> list of common problems with GNUisms.
Thanks for the link. Once I start searching for processes to kill and
files to delete I'm sure that will become a good reference. I'm
thinking that these will be the only needed external programs:
find
ps
tar
gzip ? (or something else to compress things with)
I might write a test function to the install system to verify the
existence of the correct tools and switch to the correct syntax if I
need to. Although Gentoo is my primary goal I want things to work on a
minimal system of any flavor of *nix that has bash. That goal may have
to be abandoned though. We'll see.
Regards,
--
Tres Melton
IRC & Gentoo: RiverRat
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] grub reiser4
On Mon, 2005-10-03 at 10:10 +0100, Chris Bainbridge wrote: > On 03/10/05, Mike Doty <[EMAIL PROTECTED]> wrote: > > I'd prefer if the patch was left out for amd64 users, or included via a > > use flag. reiser4 isn't yet stable or proven on amd64. > > A quick search found this quote: "The topic in channel #gentoo-amd64 > on irc.freenode.net has said "Reiser4 is evil" for more than a year." > > However http://gentoo-wiki.com/HOWTO_AMD_64 and the forum threads it > links to seem to suggest that people are successfully using reiser4 on > amd64 with recent kernels? > Yes it's true because reiser4 isn't ready for AMD64 atm. There are a couple of users that tried reiser4 and they got nothing more than data corruption because reiser4 is unstable. For somehow reiser4 isn't in the stable kernel. -- Luis Medinas <[EMAIL PROTECTED]> http://dev.gentoo.org/~metalgod Gentoo Linux Developer: AMD64,Printing,Media-Optical -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: user/group manipultaion feedback request.
On Monday 03 October 2005 13:39, Tres Melton wrote:
> I've coded the parts that
> extract and parse the information from the /etc/{passwd,group} files
I think with this you're already out of portability. /etc/passwd structure in
Linux and FreeBSD is different, and on Darwin the users part is completely
another story. Take a look to enewuser/enewgroup functions on eutils eclass.
> find
This is mostly compatible a part a couple of commands (like -printf) and the
fact that it *needs* that you give him a path to work on.
> ps
This is different from OS to OS, the Linux version is not portable. Have a
look to pgrep, but that's not completely portable, too.
> tar
As long as you use the basic commands, it should be safe. You cannot ignore
the format of the archive, tho, as just bsdtar and later GNU tars support
that.
> gzip ? (or something else to compress things with)
That's just the same.
> Although Gentoo is my primary goal I want things to work on a
> minimal system of any flavor of *nix that has bash.
You'll probably have not to use directly the /etc/{passwd,group} files, as
they are not universal. Every os uses its own ways to access those data, and
things do not get better when adding pam as a variable in all this.
Take a look to egetent, egethome functions in eutils and portability eclass if
you want to take a look to what is done now. That is still incomplete,
though, so you will probably have other things to arrange...
You're wellcome to join gentoo-alt mailing list to discuss of portability in
case :)
--
Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/
Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: grub reiser4
On Sun, 2005-10-02 at 10:02 +, Chris Bainbridge wrote: > On 02/10/05, R Hill <[EMAIL PROTECTED]> wrote: > > The grub maintainer's stance was that reiser 4 support would not be > > included in grub until it was included in gentoo-sources, not any kernel > > in portage. The grub maintainer has been AWOL for the last 9 months or > > so however, so i guess it's now up to the base-system herd. I was under > > the impression that feature-adding patches should be sent upstream. > > > > I still think it's retarded to have a reiser 4 boot partition, but > > whatever stirs your pot. ;P > > It makes sense if you're actually using reiser4 for everything else. > Why bloat your kernel with an extra FS just for /boot? The space added to a kernel for ext2 is *much* less than the overhead of using a journaling file system for /boot. You're wasting exponentially more space using reiser on /boot. The same would be true if you were using ext3, which is why you always see us suggesting using ext2 for boot. -- Chris Gianelloni Release Engineering - Strategic Lead x86 Architecture Team Games - Developer Gentoo Linux signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Interactive emerge
On Sun, 2005-10-02 at 13:21 -0400, Dan Meltzer wrote:
> Hi, I would just like some clarification if at all possible.
>
> Recently, while testing bugzilla-2.18.4 for x86 (bug # 107796) I ran
> into some interactivity. I was under the impression that emerge was
> supposed to be completely autonomous, and any user interaction should
> take place in ebuild ... config.
>
> Apparantly one of us is {in,}correct, but I cannot find any
> documentation although I'm fairly sure I have read it..
Ebuilds *should* be non-interactive. There are a few exceptions to
this, such as ones triggered by USE flags (ala webapp-config.eclass) and
ones triggered by necessity (ala games from CD).
--
Chris Gianelloni
Release Engineering - Strategic Lead
x86 Architecture Team
Games - Developer
Gentoo Linux
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] Re: grub reiser4
On Sun, 2005-10-02 at 17:43 +, Chris Bainbridge wrote: > On 02/10/05, Dan Meltzer <[EMAIL PROTECTED]> wrote: > > On 10/2/05, Chris Bainbridge <[EMAIL PROTECTED]> wrote: > > > On 02/10/05, Alec Warner <[EMAIL PROTECTED]> wrote: > > > > Chris Bainbridge wrote: > > > > > On 02/10/05, R Hill <[EMAIL PROTECTED]> wrote: > > > > >>I still think it's retarded to have a reiser 4 boot partition, but > > > > >>whatever stirs your pot. ;P > > > > > > > > > > It makes sense if you're actually using reiser4 for everything else. > > > > > Why bloat your kernel with an extra FS just for /boot? > > In addition, why bloat your fs by having a journaled filesystem for > > essentially static files? > > Because it's easier to have a single fs for / than have multiple > partitions, and try to isolate all of the things that are "essentially > static" and move them over to unjournalled file systems. Journalling > operations on /boot are responsible for filling a very, very small > percentage of my hard disk. Which is still much larger than the space needed for the ext2 driver. *grin* -- Chris Gianelloni Release Engineering - Strategic Lead x86 Architecture Team Games - Developer Gentoo Linux signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] UK Expo rota and opening times
Hi, I just wanted to remind you guys that this is about the last chance you have to send me your GPG keys to be added to the list. For instructions please see http://dev.gentoo.org/~cryos/keysigning_lwe_05.html and email me your key. Look forward to seeing you guys down at the expo in London. Thanks, Marcus -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] grub reiser4
On Sun, 2005-10-02 at 22:57 -0500, Mike Doty wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Mike Frysinger wrote: > | On Thursday 29 September 2005 02:10 pm, Chris Bainbridge wrote: > | > |>I was wondering if there's any chance of having the reiser4 patch for > |>grub (or even the whole grub-reiser4 distfile) added to the ebuild. > |>There are various bugs where people have posted patches for 0.96x > |>ebuilds which were never added and the bugs have been WONTFIXed or > |>left dangling. I've been using grub+reiser4 for about 9 months now > |>with no problems. The last reason I heard it wouldn't be added was > |>that no kernels in portage support it; I believe that's not true > |>anymore, at least mm-sources has reiser4. > | > | > | i'll ask a few devs how they feel about it before i commit it > | -mike > I'd prefer if the patch was left out for amd64 users, or included via a > use flag. reiser4 isn't yet stable or proven on amd64. Honestly no matter what your opinion of resier4 is, this patch needs to really be added. I see that amd64 has mm-sources in portage, which is a kernel from kernel.org, and it has ~amd64 KEYWORDS. The argument that we have always had was that reiser4 was not included in a kernel.org kernel. This is no longer true. Now, I can understand not *supporting* it until it hits vanilla, but we shouldn't deny adding patches that resolve issues with the FS or packages that interact with the FS just because we dislike it or don't deem the FS stable. I'd say to add the patch to grub, and if a user hoses up their system, well... they're knowingly running a very experimental kernel and an arguable file system they can pick up the pieces themselves. -- Chris Gianelloni Release Engineering - Strategic Lead x86 Architecture Team Games - Developer Gentoo Linux signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] grub reiser4
On Mon, 2005-10-03 at 10:10 +0100, Chris Bainbridge wrote: > On 03/10/05, Mike Doty <[EMAIL PROTECTED]> wrote: > > I'd prefer if the patch was left out for amd64 users, or included via a > > use flag. reiser4 isn't yet stable or proven on amd64. > > A quick search found this quote: "The topic in channel #gentoo-amd64 > on irc.freenode.net has said "Reiser4 is evil" for more than a year." > > However http://gentoo-wiki.com/HOWTO_AMD_64 and the forum threads it > links to seem to suggest that people are successfully using reiser4 on > amd64 with recent kernels? The gentoo-wiki.com site is not an official Gentoo site. Anything written there can't be considered factual or accurate, and definitely doesn't reflect on official Gentoo stance on anything, except where quoted directly from a gentoo.org site (other than the forums, and probably not planet or universe, either). That being said, it's usually correct on things. The forums has had reports of people using reiser4 on everything from their amd64 to their toaster forever, all claiming "stability" even at times when reiser4 support wouldn't compile on that platform. What I am trying to point out here is that reports in the forums should be taken with a grain of salt. I'm unaware of any testing having been done by the amd64 team recently. I am aware of several people with "stable" reiser4 systems having the file system go tits up on them, however. I don't remember what platform they were on, but I also know that they were running kernels not in the tree, which means they have questionable stability themselves, so pinpointing the file system as the actual problem is difficult, at best. My suggestion is to try it. If it works for you, then great. If it doesn't, don't come asking us, as we'll probably say something like "I told you so." Basically, I think it is perfectly fine to play around with reiser4, but I wouldn't trust it with *my* data. Not yet. -- Chris Gianelloni Release Engineering - Strategic Lead x86 Architecture Team Games - Developer Gentoo Linux signature.asc Description: This is a digitally signed message part
[gentoo-dev] Re: Re: grub reiser4
Chris Gianelloni posted <[EMAIL PROTECTED]>, excerpted below, on Mon, 03 Oct 2005 08:54:21 -0400: > On Sun, 2005-10-02 at 10:02 +, Chris Bainbridge wrote: >> On 02/10/05, R Hill <[EMAIL PROTECTED]> wrote: >> > I still think it's retarded to have a reiser 4 boot partition, but >> > whatever stirs your pot. ;P >> >> It makes sense if you're actually using reiser4 for everything else. >> Why bloat your kernel with an extra FS just for /boot? > > The space added to a kernel for ext2 is *much* less than the overhead of > using a journaling file system for /boot. You're wasting exponentially > more space using reiser on /boot. The same would be true if you were > using ext3, which is why you always see us suggesting using ext2 for > boot. Disk-space, yes. However, memory-wise, kernel memory is locked memory, not swappable. If one is already using reiserfs for other partitions, using it for boot and either not compiling ext2 or making it a module and not loading it under normal circumstances, means more efficient use of memory. Disk-space @ 50 cents a gig, tens of megs is no big deal. Memory space @ 50 dollars a gig or more, and much less of it to spare, a few tens of kBytes, particularly of locked memory, IS a big deal. (Kernel 2.6.14-rc3 ext2.ko, compiled for size on amd64, 63,839 bytes, here.) However, all the arguments based on space required for journalling go out the window with reiser4, because as I explained in a previous post, it's more literally atomic commits than traditional journalling. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman in http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Interactive emerge
maillog: 03/10/2005-08:56:57(-0400): Chris Gianelloni types
> On Sun, 2005-10-02 at 13:21 -0400, Dan Meltzer wrote:
> > Hi, I would just like some clarification if at all possible.
> >
> > Recently, while testing bugzilla-2.18.4 for x86 (bug # 107796) I ran
> > into some interactivity. I was under the impression that emerge was
> > supposed to be completely autonomous, and any user interaction should
> > take place in ebuild ... config.
> >
> > Apparantly one of us is {in,}correct, but I cannot find any
> > documentation although I'm fairly sure I have read it..
>
> Ebuilds *should* be non-interactive. There are a few exceptions to
> this, such as ones triggered by USE flags (ala webapp-config.eclass) and
> ones triggered by necessity (ala games from CD).
Does it seem like it is time for RESTRICT=interactive. Such ebuilds
would refuse to emerge if stdout is not a tty. If only there was
use-flag based RESTRICT...
--
() Georgi Georgiev () Harrison's Postulate: For every action,()
()[EMAIL PROTECTED]() there is an equal and opposite criticism. ()
() +81(90)2877-8845 ()()
pgpbYLAC9vZvf.pgp
Description: PGP signature
Re: [gentoo-dev] Interactive emerge
On Mon, 3 Oct 2005 23:15:37 +0900 Georgi Georgiev <[EMAIL PROTECTED]> wrote: | Does it seem like it is time for RESTRICT=interactive. Such ebuilds | would refuse to emerge if stdout is not a tty. If only there was | use-flag based RESTRICT... No, because then that would encourage even more people to abuse the system and write incorrect ebuilds. -- Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm pgpSnN9rZozqq.pgp Description: PGP signature
[gentoo-dev] test
-- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] test
On Tuesday 04 October 2005 19:06, Benjamin Allen wrote: what? -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpYQqCyrGVAe.pgp Description: PGP signature
Re: [gentoo-dev] Interactive emerge
Ciaran McCreesh wrote:
> On Mon, 3 Oct 2005 23:15:37 +0900 Georgi Georgiev <[EMAIL PROTECTED]> wrote:
> | Does it seem like it is time for RESTRICT=interactive. Such ebuilds
> | would refuse to emerge if stdout is not a tty. If only there was
> | use-flag based RESTRICT...
>
> No, because then that would encourage even more people to abuse the
> system and write incorrect ebuilds.
IMHO this could be enforced by some policy ("don't use
RESTRICT=interactive unless you really need it and some_group has given
you the ok")...
Cheers,
-jkt
--
cd /local/pub && more beer > /dev/mouth
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] Interactive emerge
On Mon, 2005-10-03 at 19:39 +0200, Jan Kundrát wrote:
> Ciaran McCreesh wrote:
> > On Mon, 3 Oct 2005 23:15:37 +0900 Georgi Georgiev <[EMAIL PROTECTED]> wrote:
> > | Does it seem like it is time for RESTRICT=interactive. Such ebuilds
> > | would refuse to emerge if stdout is not a tty. If only there was
> > | use-flag based RESTRICT...
> >
> > No, because then that would encourage even more people to abuse the
> > system and write incorrect ebuilds.
>
> IMHO this could be enforced by some policy ("don't use
> RESTRICT=interactive unless you really need it and some_group has given
> you the ok")...
No, it shouldn't. interactive ebuilds make remote updating very
time-consuming (you have to check wether it wants you to interact with i
or not yet) and are usually not needed - just ask the user to run ebuild
foo config (or whatever does thw job) manually.
--
Stand still, and let the rest of the universe move
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] Interactive emerge
On Mon, Oct 03, 2005 at 07:39:05PM +0200, Jan Kundr?t wrote:
> Ciaran McCreesh wrote:
> > On Mon, 3 Oct 2005 23:15:37 +0900 Georgi Georgiev <[EMAIL PROTECTED]> wrote:
> > | Does it seem like it is time for RESTRICT=interactive. Such ebuilds
> > | would refuse to emerge if stdout is not a tty. If only there was
> > | use-flag based RESTRICT...
> >
> > No, because then that would encourage even more people to abuse the
> > system and write incorrect ebuilds.
>
> IMHO this could be enforced by some policy ("don't use
> RESTRICT=interactive unless you really need it and some_group has given
> you the ok")...
Ebuilds are non-interactive compile/install... that's the design, and
intention of them.
I don't like opening the possibility for people to use it, mainly due
to the fact
A) give me an instance when it's required for compile
B) interactive build scripts are idiotic (writing expect scripts for a
tinderbox setup is proof enough of this)
C) 15 hour upgrade/build, hanging an hour into it is going to be an
ass biter.
Yes, we can slap some warning into the UI tools for C, but people will
still miss it on occasion, and it'll piss them off something fierce
(just the same as a single failure in building results in emerge
stopping).
It's a bad idea from where I sit.
~harring
pgpl89BfLrpEf.pgp
Description: PGP signature
Re: [gentoo-dev] Interactive emerge
On Mon, 2005-10-03 at 17:51 +0100, Ciaran McCreesh wrote: > On Mon, 3 Oct 2005 23:15:37 +0900 Georgi Georgiev <[EMAIL PROTECTED]> wrote: > | Does it seem like it is time for RESTRICT=interactive. Such ebuilds > | would refuse to emerge if stdout is not a tty. If only there was > | use-flag based RESTRICT... > > No, because then that would encourage even more people to abuse the > system and write incorrect ebuilds. CD_ROOT=/path/to/ut2004 emerge ut2004 That is non-interactive, assuming all the data is copied to that path. So interactivity isn't guaranteed. -- Chris Gianelloni Release Engineering - Strategic Lead x86 Architecture Team Games - Developer Gentoo Linux signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Interactive emerge
On Mon, 2005-10-03 at 13:23 -0500, Brian Harring wrote: > C) 15 hour upgrade/build, hanging an hour into it is going to be an > ass biter. This is actually why I've been doing something I would normally *not* do and have been breaking up some games ebuilds that require a CD into a $foo and $foo-data set. That way the on-disc data is only ever retrieved once, and isn't required for subsequent upgrades. (yeah, doesn't help on -e, though) -- Chris Gianelloni Release Engineering - Strategic Lead x86 Architecture Team Games - Developer Gentoo Linux signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Interactive emerge
Brian Harring wrote:
> Ebuilds are non-interactive compile/install... that's the design, and
> intention of them.
Sure, I thought that RESTRICT=interactive would just tell the user that
she would have to provide some feedback in cases like those that
wolf31o2 mentioned ("games from CD").
> I don't like opening the possibility for people to use it, mainly due
> to the fact
> A) give me an instance when it's required for compile
> B) interactive build scripts are idiotic (writing expect scripts for a
> tinderbox setup is proof enough of this)
> C) 15 hour upgrade/build, hanging an hour into it is going to be an
> ass biter.
ok.
Cheers,
-jkt
--
cd /local/pub && more beer > /dev/mouth
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] deprecation of SANDBOX_DISABLED
On Wed, 2005-09-28 at 03:05 -0500, Brian Harring wrote: > Hola. > > Subject says it all; SANDBOX_DISABLED functions as (essentially) > RESTRICT="sandbox", except sandbox is left on for pkg_setup . > > This is pretty much redundant, considering it's usage. People stick > it in the global scope; if you _must_ turn off the sandbox for a > specific phase, use SANDBOX_ON=0/1 instead. If you need to disable > sandbox across the board, restrict="sandbox" is your friend. > > Since there are still ebuilds in the tree that would be schmooked by > it, it's not going to hit in the coming version, but I'd expect it to > be dead next version after unless people have a really good reason why > it should live on. > > So... thoughts? Yes it's minor, but it's a matter of cleaning > up/simplifying portage code, and removing redundancy. > Sounds sane. -- Martin Schlemmer signature.asc Description: This is a digitally signed message part
