headers
Dave Nebinger | 1 Oct 2005 03:59

Question about java builds and the sandbox...

Okay, hopefully this works as I expect, but...

If I have an ant build.xml file that creates and populates an /opt/dnebing 
directory but runs as part of an ebuild, will it actually create 
the /opt/dnebing directory or is it made as part of the image 
in /var/tmp/portage/dnebing/image directory?

I'm hoping it is the latter, but if not I guess I'd need to strip installation 
stuff from the build.xml file and put the appropriate commands in the ebuild 
script.

Can someone shed a little light on this for me?

Thanks!
--

-- 
gentoo-dev <at> gentoo.org mailing list
Permalink | Reply | 3 comments |
headers
Tres Melton | 1 Oct 2005 05:04
Picon

Re: Question about java builds and the sandbox...

On Fri, 2005-09-30 at 21:59 -0400, Dave Nebinger wrote:
> Okay, hopefully this works as I expect, but...
> 
> If I have an ant build.xml file that creates and populates an /opt/dnebing 
> directory but runs as part of an ebuild, will it actually create 
> the /opt/dnebing directory or is it made as part of the image 
> in /var/tmp/portage/dnebing/image directory?
> 
> I'm hoping it is the latter, but if not I guess I'd need to strip installation 
> stuff from the build.xml file and put the appropriate commands in the ebuild 
> script.

I'm pretty sure that the files are supposed to be installed to the
${ROOT}/${P}/
directory.  It is the merge command to ebuild that actually moves the
files into the live filesystem.

> Can someone shed a little light on this for me?
> 
> Thanks!
-- 
Tres Melton
IRC & Gentoo: RiverRat

--

-- 
gentoo-dev <at> gentoo.org mailing list
Permalink | Reply | 0 comments |
headers
Saleem A. | 1 Oct 2005 05:14
Picon
Favicon

Re: Question about java builds and the sandbox...

On Fri, 30 Sep 2005, Dave Nebinger wrote:

> If I have an ant build.xml file that creates and populates an /opt/dnebing 
> directory but runs as part of an ebuild, will it actually create 
> the /opt/dnebing directory or is it made as part of the image 
> in /var/tmp/portage/dnebing/image directory?

It is better to have a separate task for the install and the build.  You
can set the default task to the install, but call it with just the build
task.

On a related sidenote, please do not expect that the install/build is in
/var/tmp/portage/dnebing/image.  $ROOT can be something other than / in
theory (not 100% sure that it is fully supported yet or not).  Also, you
can change the tmp dir (PORTAGE_TMPDIR in /etc/make.conf).  You should
be generic enough to handle any of those cases.  If you are looking for
a very generic build.xml check bug #92014.

I hope that helps.  Please feel free to ask any other questions that you
may have.

Saleem Abdulrasool
compnerd (at) gentoo (dot) org
Permalink | Reply | 1 comment |
headers
Mike Frysinger | 1 Oct 2005 06:51
Picon
Favicon
Gravatar

Re: Question about java builds and the sandbox...

On Friday 30 September 2005 11:14 pm, Saleem A. wrote:
> $ROOT can be something other than / in
> theory (not 100% sure that it is fully supported yet or not).

if there is a package which doesnt support ROOT, it is broken and needs to be 
fixed ... nothing should ever hard code / in pkg_* functions
-mike
--

-- 
gentoo-dev <at> gentoo.org mailing list
Permalink | Reply | 0 comments |
headers
Daniel Stiefelmaier | 1 Oct 2005 22:19
Picon
Favicon

Improved ebuild information

Hi!

I just opened this in gentoo-portage-dev, but Jason Stubbs told me my 
ideas are either bad or belong to THIS list, so i try my luck again...

I'd like to have a functionality that prints out what the useflags of a 
ebuild are good for. Some are obvious, others are not. Example:
The useflag "xprint" sounds like printing support, but doesn't tell if 
you need it if you use cups or the kde-printing system or... whatever.
Jason stated:

Take the USE flag "perl", for example. It has the description "Adds 
support/bindings for the Perl language." but for mysql setting it enables the 
installation of some support scripts that just happen to be written in perl.

Another thing is, that i'd like to get some additional information on 
some ebuilds.
Like HOWTOs, known issues, configuration help, related ebuilds (not 
dependant but useful together)
In my opinion, the easiest way would be a wiki.
Ebuilds could contain an additional field "EBUILDNOTES" or the like, 
providing the URL.
An even more simple way would be to have portage tools (eix, emerge) 
print an automatically generated link like
http://www.gentoo-wiki.com/Ebuild:www-client/mozilla-firefox
as mediawiki pages always have a discussion page attached, this could be 
used to get in touch with the maintainers of that package. (Only if they 
want that. This could be noted on the page)

thanks for reading and answering :)
(Continue reading)

Permalink | Reply | 14 comments |
headers
Ciaran McCreesh | 1 Oct 2005 22:22
Picon
Favicon

Re: Improved ebuild information

On Sat, 01 Oct 2005 22:19:39 +0200 Daniel Stiefelmaier
<mail <at> stiefelweb.de> wrote:
| I'd like to have a functionality that prints out what the useflags of
| a ebuild are good for. Some are obvious, others are not. Example:
| The useflag "xprint" sounds like printing support, but doesn't tell
| if you need it if you use cups or the kde-printing system or...
| whatever.

We've discussed adding this to metadata.xml a few times in the past,
but every time there was opposition from a vocal minority of one who
claimed that USE flags should always do exactly the same thing for
every package.

--

-- 
Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm
Permalink | Reply | 10 comments |
headers
Simon Stelling | 1 Oct 2005 22:25
Picon
Favicon

Re: Improved ebuild information

Hi,

Daniel Stiefelmaier wrote:
> In my opinion, the easiest way would be a wiki.

Indeed. But why do you need to modify all the ebuilds?

> An even more simple way would be to have portage tools (eix, emerge) 
> print an automatically generated link like
> http://www.gentoo-wiki.com/Ebuild:www-client/mozilla-firefox
> as mediawiki pages always have a discussion page attached, this could be 
> used to get in touch with the maintainers of that package. (Only if they 
> want that. This could be noted on the page)

Wikis are very popular, but they aren't the solution to every problem in the 
world. If you want to contact the maintainer, write a mail, use IRC, or assign 
bugs to them, but why do we need another (communication) channel?
It'd be great if you could animate people to concentrate useful information 
about a package in a certain place, but that's really not the job of an ebuild 
or portage.

Regards,

-- 
Simon Stelling
Gentoo/AMD64 Operational Co-Lead
blubb <at> gentoo.org
--

-- 
gentoo-dev <at> gentoo.org mailing list
(Continue reading)

Permalink | Reply | 2 comments |
headers
Daniel Stiefelmaier | 2 Oct 2005 02:10
Picon
Favicon

Re: Improved ebuild information


>We've discussed adding this to metadata.xml a few times in the past,
>but every time there was opposition from a vocal minority of one who
>claimed that USE flags should always do exactly the same thing for
>every package.
>  
>
why do minorities rule?
Actually i agree that in general use flags should have a consistent meaning.
But anyway, if "perl" adds support for perl, the user might want to know 
what it is good for in this package. or "plugins" could list the plugins 
that would be added.

What tool ever would display the use flags description, it could use 
those from
/usr/portage/profiles/use.desc by default, which may be overwriten in 
metadata.xml

greetings,
Caliga
--

-- 
gentoo-dev <at> gentoo.org mailing list
Permalink | Reply | 1 comment |
headers
Daniel Stiefelmaier | 2 Oct 2005 02:46
Picon
Favicon

Re: Improved ebuild information


>> In my opinion, the easiest way would be a wiki.
>
>
> Indeed. But why do you need to modify all the ebuilds?

do i have to? of course it is not necessary to modify 10k ebuilds in a 
week. The line could be added on the next regular update. And as said 
below, it could also be generated automatically by the tool that reads 
the packages metadata.

> Wikis are very popular, but they aren't the solution to every problem 
> in the world. If you want to contact the maintainer, write a mail, use 
> IRC, or assign bugs to them, but why do we need another 
> (communication) channel?

You're right, maybe that discussion thing is not so useful. The only 
thing advantage i see is that the inhibition to participate is very low 
for a wiki. I helped with inkscape.org and met people that never use 
CVS, IRC, Jabber... Those can still write in the wiki. And still, if the 
discussion page should not be used for feedback, maintainers could state 
how they prefer to be contacted.

> It'd be great if you could animate people to concentrate useful 
> information about a package in a certain place, but that's really not 
> the job of an ebuild or portage.

That sounds like
"your target is good, your way may work, but your way is wrong. i don't 
know the right way"
(Continue reading)

Permalink | Reply | 1 comment |
headers
Alec Warner | 2 Oct 2005 04:35
Picon
Favicon

Re: Improved ebuild information


Ok really first off, I am not a gentoo developer, just to let you know :)

First off, everything here is basically taken out of context from
gentoo-portage-dev, so the only sane responses ( to this mail, not the
other one, which was different ) are going to be from people who read both.
> 
>>> In my opinion, the easiest way would be a wiki.
>>
>>
>>
>> Indeed. But why do you need to modify all the ebuilds?
> 
> 
> do i have to? of course it is not necessary to modify 10k ebuilds in a
> week. The line could be added on the next regular update. And as said
> below, it could also be generated automatically by the tool that reads
> the packages metadata.
> 

Regardless of where this data is going, SOME{ONE,THING} has to compile
it all.  You spoke on the other ML of HOW-TO links and all manner of
info.  That info is great.  The problem is convincing ebuild developers
to compile the data in the first place, and keep it accurate.  That is
why we suggested you try your ideas here.  Writing this stuff into a
tool or patching portage is useless if no one compiles/updates this
information.

> All that has to be done is create a way to print the path to a wiki-page.
> Maybe auto-created by eix. Or maybe a new tool named "einfo" that prints
(Continue reading)

Permalink | Reply | 0 comments |

Gmane