public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: 320095285153-0001@t-online.de (Achim Gottinger)
To: gentoo-dev@gentoo.org
Subject: Re: [gentoo-dev] interactive packages?
Date: Mon Feb  5 15:09:02 2001	[thread overview]
Message-ID: <3A7F1E40.FA4D7C75@gottinger.de> (raw)
In-Reply-To: 20010205131802.A26227@alkaline.anarchy

pbg1854@garnet.acns.fsu.edu wrote:

> Ok...
>
> How about we make an option to ebuild that makes the build process
> interactive. We could make that option set a variable in the ebuild
> script, which we would then check during the individual steps in the
> process.. for example,
>
> if [ "${INTERACTIVE}" ]; then
>         make menuconfig
> else
>         cp "${FILESDIR}/config-${KV}" ${WORKDIR}/linux/.config
>         yes "" | make oldconfig
> fi

Thats what I ment by the USE variable method.

>
> Then you could run ebuild -i merge or something like that.
>

We do not use flags for ebuild at the moment. Maybe in future

>
> A few notes:
> I like using make oldconfig, because it automatically takes care of
> autoconf.h, and version.h for you, and makes sure everything is
> configured right. I'd use yes "" | make oldconfig in the
> non-interactive version, that way if there are any variables missing
> in the .config file, they will get the default value.

That sounds good. I think I saw that option last week in some magazine.

>
>
> I also thought it would be a good idea if the kernels were installed
> with a suffix determining the version of the kernel,
> i.e. bzImage-2.4.0 rather than just bzImage; that way multiple kernels
> can be installed at the same time. I like to do this, especially when
> installing a new kernel, in case the new one won't boot or has some
> kind of bug in it, I can go back to the old one. Then you could merge
> the new kernel, reboot, and unmerge the old one after you're satisfied
> the new one works.

But what if you configure manual and have different kernels of the same version?

>
>
> If you want, I'll try to modify the ebuild script to add interactive
> building support, and work on a sample kernel ebuild. Adding
> interactive support shouldn't require any modifications in the
> packages, I'm pretty sure.
>
> Oh... and one more thing... I'm having problems w/ the make check
> stage while building glibc-2.2.1. I'm trying to figure out why right
> now. It just says "Timed out" or something like that. I'll give you
> more info after I run make check again.

Hmm, sounds like LFS <-> low latency problem. I saw that over here once but at
that time
I had a lot of parallel build processes running.

>
>

achim~

>
> Pete
>
> On Mon, Feb 05, 2001 at 03:03:38PM +0100, Achim Gottinger wrote:
> > Pete Gavin wrote:
> >
> > > Hi,
> > >
> > > I was wondering... Is it required that an ebuild script be completely
> > > non-interactive?
> >
> > Yes, otherwise there would be no autobuild.
> >
> > > I have a few ideas for the kernel configuration
> > > scripts. I think it might be cool for the for the ebuild to ask the
> > > installer if he/she wants to load a .config file from somewhere else, then
> > > run make menuconfig. That way all the modules and stuff can be removed
> > > with portage-unmerge.
> >
> > You can do this.
> > After running "ebuild linux.... unpack" cd to
> > /tmp/portage/linux.../work/linux
> > run "make menuconfig/xconfig"
> > Then continue with ebuild linux... compile
> >
> > Another possibility would be using the "config" function in ebuild. This was
> > normaly intedet to be used
> > for an opional additional configuration-layer. And should normaly modify the
> > package configuration
> > files from templates/databses whatever. Normaly this functions hsould be
> > called after pkg_merge.
> > But since we have no configuration layer right now and config is only used by
> > a few packages (for example
> > qmail runs config-fast from within the config function) we could use the
> > config function for such an
> > interactive thing.
> > Another solution could be using a USE variable to decide if the manual
> > configuration you described should be
> > run or a variable that just triggers if a private config file should be used
> > instead of the default one. Or we could make a sepearate kernel package that
> > does these manual steps.
> >
> > But what do you think about that. The kernel ebuild looks if a file (for
> > example /etc/kernel/[version].config) exists. If so it uses this instead of
> > the default one.
> > If you want to configure the kernel for the first time you can do it as I
> > described above. The copy the .config file to /etc/kernel/[version].config
> > and the next time you compile the kernel your private config file gets used.
> >
> > achim~
> >
> > >
> > > Pete
> > >
> > > _______________________________________________
> > > gentoo-dev mailing list
> > > gentoo-dev@gentoo.org
> > > http://www.gentoo.org/mailman/listinfo/gentoo-dev
> >
> >
> > _______________________________________________
> > gentoo-dev mailing list
> > gentoo-dev@gentoo.org
> > http://www.gentoo.org/mailman/listinfo/gentoo-dev
>
> _______________________________________________
> gentoo-dev mailing list
> gentoo-dev@gentoo.org
> http://www.gentoo.org/mailman/listinfo/gentoo-dev




      reply	other threads:[~2001-02-05 22:08 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-02-05  7:01 [gentoo-dev] interactive packages? Pete Gavin
2001-02-05  7:30 ` Achim Gottinger
2001-02-05 11:20   ` pbg1854
2001-02-05 15:09     ` Achim Gottinger [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3A7F1E40.FA4D7C75@gottinger.de \
    --to=320095285153-0001@t-online.de \
    --cc=gentoo-dev@gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox