Bug 43357 – software development ebuild wrapper, development mode, and howto

• Product: Portage Development
• Status: RESOLVED WONTFIX

[Description Aaron Peterson 2004-03-01 02:42:30 UTC]

I need more help/documentation on how to do software development on.. any linux system...,  however in my starving delusions, I saw the way that I think it should be. 

I want to use/create an  option to switch an ebuild into development mode doing:
1. uncompress the source into /usr/src 
2. keep it from being overwritten each time the package is emerged.
3.  have it's own ccache setting. (off for portage, on for development mode packages)
4. have an ability to re tarball it at the end.
5. copy the ebuild to the /usr/src directory (or some other "special" place) where it can be edited, overriding the regular ebuild, and automatic diff.. (well, cvs)
6. be kept in a configured cvs or subversion directory
7. integrate with kdevelop or other IDE's like ajunta(?)


Background:
I've seen ebuild howto's, but I'm trying to modify the package.
The source doesn't seem to stick arround in my /usr/src directory, and when I modify a package and it was successfull, I don't want to create a whole new ebuild and tarball.

an answer to my questioning on IRC was simply: local repo and ccache
I asked a friend (a source mage developer) how he does it, it was basically the same, but it had the "spell"(ebuild) overriding concept in it.

Rational for talking about this on bugzilla:
I am most comfortable with the bugzilla web-accessability and email, The forums don't seem to have patch accepting capability either.

Reproducible: Always
Steps to Reproduce:
1.
2.
3.

[Comment 1 Aaron Peterson 2004-03-01 03:11:05 UTC]

execution ideas:
***1.****
emerge --develop_mode=1 kdeaccessability
this package has a cvs counterpart, use it instead? y/n?
do you want to create a new slot y/n?
getting source
...copying ebuild to /usr/portage/development/app-kde/ (or whatever combo it is)
creating local cvs repository
extracting source to /usr/src/app-kde/
* Mode succesfully switched  for kdeaccessibility package

**2..  upgrade of package behavior*** 
emerge sync
emerge kdeaccessability -u
kdeaccessability is in development_mode
downloading source
extracting old source
extracting new source
creating diff file
dry run attempt to apply patch to /usr/src/app-kde/kdeaccessability
simulated patching succeeded
applying patch... success
copying source to sandbox..ok
make ./config...
...

***3.. re entry into portage/package***
emerge kdeaccessabiltiy --package
makeing clean
making mrproper (or whatever this is)
tarballing,
adding to the local rsync mirror mask section
name of the package shall be:kdeaccessabiltiy-3.2.1-date_like_cvs_snapshot-system-name



implementation/design ideas:
this doesn't seem like it would be too hard to me, except for 
1. possible high failure of some of the automatic patch creation,  
2.the possible interactive nature of the script on some questions (which is not in the character of gentoo cli tools, but should perhaps become so as an option)
3. possible ebuild non standard way of extracting source
4. tricking the ebuild into believing that it has extracted the sources?

I suspect that 3 and 4 might not be bad because of the ebuild format, some of the functions could just  be skipped, however sometimes there are special actions that take place in these areas.


Possible problems:
when do we have to re emerge dependant packages?

I have no idea how to integrate this with kdevelop or ajunta, but it just being there should be the major step

[Comment 2 Marius Mauch (RETIRED) 2004-06-09 20:36:03 UTC]

I don't like this. For development use the ebuild(1) command and patches in $FILESDIR. Nick, Jason, Mike: opinions on this one ?

[Comment 3 Aaron Peterson 2004-06-10 03:00:28 UTC]

 Marius
Thanks for looking at this bug!
(sorry docs-team for adding ya'll)

The funny thing, is that many USERS want to develop software/ or should be coerced into doing so, rather than just complaining about how crappy stuff is.

We need to make it easier for people to develop GOOD software, and solve problems on their own.

This is a very general bug, unfortunately...
I did one bug to cover a
1. ebuild wrapper idea
2. or actuall emerge mode
3. or provide a guide on how to tweak the source code of a project that is to be installed on a live system, or to develop new software on gentoo, having it be managed by portage.. and directly made available to others.

I have seen options to not unpack source, in the work directory..  I guess this is mostly a request for some sort of HOWTO. or better yet, a Discoverable way to develop software for linux on gentoo.

BSD has a discoverable way to develop software.. the source code just lies in /usr/src 

edit away...
./configure
make
make install

in gentoo... its..
???
edit away
????

I think I can fill in some of the ??'s

emerge --unpack
find directory where it unpacked the stuff
editaway
edit ebuild if needed, put in portage overlay.. which has to be enabled
emerge --don'tunpack

**********
I spent over a week figuring out how to edit genkernel!

I searched for howto's and all the stuff that I could think of.

There is an ebuild howto...   but where's the development howto?

* I may not be the brightest peanut in the turd, but I actually try to skip things that only wanker nerds would know when I'm solving a problem in linux..  There are a lot of usability problems around.

[Comment 4 Brian Harring (RETIRED) 2005-02-28 00:13:06 UTC]

I uh... don't like this (nor does marius going by earlier comments).
A seperate package for ebuild development (abeni for example) seems saner to me.