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.
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
I don't like this. For development use the ebuild(1) command and patches in $FILESDIR. Nick, Jason, Mike: opinions on this one ?
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.
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.
