Returning a few messages back to the issue with calling sudo: it would seem
to me that the solution is to check to see if sudo is installed. If it's
installed, ask if you want to install the builddeps, and if it's not, just
list the builddeps as it already does. The majority of users will have sud
On Wed, Jun 03, 2009 at 05:59:43PM +0200, Martin Baehr wrote:
> On Wed, Jun 03, 2009 at 11:34:34AM -0400, Michael K. Johnson wrote:
> > > another goal that is often requested is to be able to install all needed
> > > compilation tools for local (non conary) use.
> > That should be a group or simpl
On Wed, Jun 03, 2009 at 11:34:34AM -0400, Michael K. Johnson wrote:
> > another goal that is often requested is to be able to install all needed
> > compilation tools for local (non conary) use.
> That should be a group or simple list of packages. Making a recipe
> do that is kind of making use o
On Wed, Jun 03, 2009 at 03:56:54PM +0200, Martin Baehr wrote:
> On Wed, Jun 03, 2009 at 09:30:18AM -0400, Michael K. Johnson wrote:
> > First, I want to keep the sights on the end goal, which I conceive
> > to be, fundamentally, quick builds for doing dependency discovery
> > and for local installs
On Wed, Jun 03, 2009 at 09:30:18AM -0400, Michael K. Johnson wrote:
> First, I want to keep the sights on the end goal, which I conceive
> to be, fundamentally, quick builds for doing dependency discovery
> and for local installs for initial testing.
another goal that is often requested is to be a
First, I want to keep the sights on the end goal, which I conceive
to be, fundamentally, quick builds for doing dependency discovery
and for local installs for initial testing.
The end goal is to be able to use rMake for this as well -- to have
a "dependency discovery chroot" that has *everything*
I've been thinking about this as well. To put it in the proper context
(no pun intended) aren't we presently exploring a Foresight use case and
the associated developer workflow that is possibly general enough to be
of benefit outside of Foresight? From my perspective, we're looking at
the situatio
You could have it just ask your user password if it needs to and use sudo
(or a library, or whatever). *only* the installation of buildreqs would be
done as root, and it would drop back to the regular user for building the
package.
Jack Doerner
"Killing you and giving you good adv
On Tue, Jun 02, 2009 at 09:03:55PM +0200, Martin Bähr wrote:
> On Tue, Jun 02, 2009 at 01:51:20PM -0400, Michael K. Johnson wrote:
> > Well, it's more that this is more subtle than it appears at first.
> > build requirements can depend on the flavor you are building,
>
> well, the flavor should ei
On Tue, Jun 02, 2009 at 01:51:20PM -0400, Michael K. Johnson wrote:
> Well, it's more that this is more subtle than it appears at first.
> build requirements can depend on the flavor you are building,
well, the flavor should either be whatever fits the system, or whatever
would be built when one r
Well, it's more that this is more subtle than it appears at first.
build requirements can depend on the flavor you are building, and
so this fundamentally means that either
* You have to have a command that runs as root that loads recipes.
* You have to run a command as a user that causes packages
On Mon, Jun 1, 2009 at 10:06 PM, Jack Doerner wrote:
> ooo... I would like to second this request - it's one of the things I've
> long thought missing.
> As a related request, when you build things in cvc and don't have the
> build-deps it whines and fails (at least when building in a personal rep
ooo... I would like to second this request - it's one of the things I've
long thought missing.
As a related request, when you build things in cvc and don't have the
build-deps it whines and fails (at least when building in a personal repo
context and not fl:2-whatever). It would be nice if it could
13 matches
Mail list logo
