[gentoo-dev] Gentoo as a development platform

[gentoo-dev] Gentoo as a development platform

[Daniel Drake]

Hi,

Quite often, I use Gentoo's from-source nature to my advantage when developing
or testing software packages.

Gentoo is fairly well oriented for this kind of environment, but it's not
brilliant. As an example, foo-3.2.1 (the latest version) is installed on my
system, but more recently, they fixed a critical bug in the upstream CVS tree
which I'd like to test the fix for. It's not dead simple for me to do this - I
want to use the CVS sources with the ebuild already in portage. I have to use
"ebuild foo-3.2.1.ebuild unpack" to extract the sources, then manually replace
them with my CVS checkout. Or checkout CVS, make a new tarball, call it
foo-3.2.1.tar.bz2, redigest and remerge the ebuild. Or I could create a
foo-cvs ebuild and go to the trouble of making it mirror the contents of
foo-3.2.1.ebuild exactly.

It's great that its *possible* right now thanks to portage and co, but I'm
interested in ways of making this easier. Before I give this more thought, I'd
be interested to know if anyone has already got any scripts or tips :)

Thanks,
Daniel
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Gentoo as a development platform

[Francesco Riosa]

Daniel Drake wrote:

>Hi,
>
>Quite often, I use Gentoo's from-source nature to my advantage when developing
>or testing software packages.
>
>Gentoo is fairly well oriented for this kind of environment, but it's not
>brilliant. As an example, foo-3.2.1 (the latest version) is installed on my
>system, but more recently, they fixed a critical bug in the upstream CVS tree
>which I'd like to test the fix for. It's not dead simple for me to do this - I
>want to use the CVS sources with the ebuild already in portage. I have to use
>"ebuild foo-3.2.1.ebuild unpack" to extract the sources, then manually replace
>them with my CVS checkout. Or checkout CVS, make a new tarball, call it
>foo-3.2.1.tar.bz2, redigest and remerge the ebuild. Or I could create a
>foo-cvs ebuild and go to the trouble of making it mirror the contents of
>foo-3.2.1.ebuild exactly.
>
>It's great that its *possible* right now thanks to portage and co, but I'm
>interested in ways of making this easier. Before I give this more thought, I'd
>be interested to know if anyone has already got any scripts or tips :)
>
>Thanks,
>Daniel
>  
>
Why do you semply add a "cat-ego/pack-cvs/pack-cvs.ebuild" near
"cat-ego/pack/pack.ebuild" without get bothered with virtual and similar
you can simply unmerge and remerge the brother package.
There are many examples of merging from cvs in portage tree.

just my my 1*10-7 cents


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Gentoo as a development platform

[Daniel Drake]

Francesco Riosa wrote:
> Why do you semply add a "cat-ego/pack-cvs/pack-cvs.ebuild" near
> "cat-ego/pack/pack.ebuild" without get bothered with virtual and similar
> you can simply unmerge and remerge the brother package.
> There are many examples of merging from cvs in portage tree.

Portage doesn't contain many cvs ebuilds. Writing one might not be that much
hassle, but why should I have to? We already have functional ebuilds to build
that particular package, and I have some slightly newer source code (e.g. in
my homedir) that I want it to build instead.

If I did write a cvs ebuild, it would check out the sources *again* from CVS,
into /usr/portage/distfiles (I guess...). This is redundant and will take
quite a bit of time for larger packages. While this not that much of a
problem, one of my motives behind this is that I want to improve productivity.
Writing an ebuild *again* which checks out the sources *again* doesn't really
go in this direction.

Daniel
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Gentoo as a development platform

[Robert Paskowitz]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

 > Portage doesn't contain many cvs ebuilds. Writing one might not be
that much
> hassle, but why should I have to? We already have functional ebuilds to build
> that particular package, and I have some slightly newer source code (e.g. in
> my homedir) that I want it to build instead.
> 
> If I did write a cvs ebuild, it would check out the sources *again* from CVS,
> into /usr/portage/distfiles (I guess...). This is redundant and will take
> quite a bit of time for larger packages. 

After an initial checkout, it does cvs up's to keep it up to date, so it
would not be that much downloading. The source is kept in
/usr/portage/distfiles/cvs-src. Also, if you planned on using a setup
like this, there wouldn't really be a need to have the source in your
home directory as well.

While this not that much of a
> problem, one of my motives behind this is that I want to improve productivity.
> Writing an ebuild *again* which checks out the sources *again* doesn't really
> go in this direction.
> 

Most cvs ebuilds I've seen are nearly identical to a non-cvs ebuild. The
only changes that should be required might be related to running autogen
before configure, besides that, the build process should not need to be
changed.

I think this is the 'scripts or tips' type thing that most people are
doing now. As for extending gentoo or portage to do it more seemlessly,
well, you'd need to get hacking on portage to do that. Combining the
power of a cvs ebuild with a regular one would probably not be all that
difficult. Having portage take your own tree from a particular user's
home directory on the other hand seems like a bit of a stretch, and no
necessarily all that useful.

Robert
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCYaorZwjIiODIZ4oRAvAeAJ0TQNY6b9VRf9dZL2IdouuV92ohCACfaj9K
xbQznSFNGnVPCEiRFcE1QJA=
=1NjA
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Gentoo as a development platform

[Daniel Drake]

Robert Paskowitz wrote:
> Also, if you planned on using a setup
> like this, there wouldn't really be a need to have the source in your
> home directory as well.

I hack on the source in my home directory. I take automatic backups of my home
directory. I don't really want to hack in /usr/portage/distfiles/ or take
backups of that. I might not want portage to do a "cvs update" of the sources
when I ask it to merge the ebuild - I might be deliberately lagging a few
revisions behind.

> Most cvs ebuilds I've seen are nearly identical to a non-cvs ebuild.

This is one element of redundancy that I'd like to address.

> Having portage take your own tree from a particular user's
> home directory on the other hand seems like a bit of a stretch, and no
> necessarily all that useful.

I would find this useful, but perhaps the things I'm thinking of are just
suited to my style of working rather than a general development scenario.

Daniel
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Gentoo as a development platform

[Malte S. Stretz]

On Sunday 17 April 2005 03:03 CET Daniel Drake wrote:
> Robert Paskowitz wrote:
>[...]
> > Having portage take your own tree from a particular user's
> > home directory on the other hand seems like a bit of a stretch, and no
> > necessarily all that useful.
>
> I would find this useful, but perhaps the things I'm thinking of are just
> suited to my style of working rather than a general development scenario.

I don't think so;  from time to time when I hacked on KDE or SpamAssassin, I 
thought a feature like the ones you described (ie. treat the ebuilds as 
mere recipes to build some codebase) would be very cool.

Cheers,
Malte

-- 
[SGT] Simon G. Tatham: "How to Report Bugs Effectively"
      <http://www.chiark.greenend.org.uk/~sgtatham/bugs.html>
[ESR] Eric S. Raymond: "How To Ask Questions The Smart Way"
      <http://www.catb.org/~esr/faqs/smart-questions.html>
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Gentoo as a development platform

[Paul de Vrieze]

[-- Attachment #1: Type: text/plain, Size: 1529 bytes --]

On Sunday 17 April 2005 02:07, Daniel Drake wrote:
> Francesco Riosa wrote:
> > Why do you semply add a "cat-ego/pack-cvs/pack-cvs.ebuild" near
> > "cat-ego/pack/pack.ebuild" without get bothered with virtual and similar
> > you can simply unmerge and remerge the brother package.
> > There are many examples of merging from cvs in portage tree.
>
> Portage doesn't contain many cvs ebuilds. Writing one might not be that
> much hassle, but why should I have to? We already have functional ebuilds
> to build that particular package, and I have some slightly newer source
> code (e.g. in my homedir) that I want it to build instead.
>
> If I did write a cvs ebuild, it would check out the sources *again* from
> CVS, into /usr/portage/distfiles (I guess...). This is redundant and will
> take quite a bit of time for larger packages. While this not that much of a
> problem, one of my motives behind this is that I want to improve
> productivity. Writing an ebuild *again* which checks out the sources
> *again* doesn't really go in this direction.

My approach to this problem is most of the time to do the first steps on the 
cvs tree (make -f Makefile.cvs) to create the configure script. Then pack 
this up in a tarbal. Copy the old ebuild to my overlay, with a new name (or 
revision in the -r990 -r999 range). Change the source location in the new 
ebuild. Digest the stuff. And emerge it.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Gentoo as a development platform

[Brian Harring]

On Sun, Apr 17, 2005 at 12:36:19AM +0100, Daniel Drake wrote:
> Hi,
> 
> Quite often, I use Gentoo's from-source nature to my advantage when developing
> or testing software packages.
> 
> Gentoo is fairly well oriented for this kind of environment, but it's not
> brilliant. As an example, foo-3.2.1 (the latest version) is installed on my
> system, but more recently, they fixed a critical bug in the upstream CVS tree
> which I'd like to test the fix for. It's not dead simple for me to do this - I
> want to use the CVS sources with the ebuild already in portage. I have to use
> "ebuild foo-3.2.1.ebuild unpack" to extract the sources, then manually replace
> them with my CVS checkout. Or checkout CVS, make a new tarball, call it
> foo-3.2.1.tar.bz2, redigest and remerge the ebuild. Or I could create a
> foo-cvs ebuild and go to the trouble of making it mirror the contents of
> foo-3.2.1.ebuild exactly.
> 
> It's great that its *possible* right now thanks to portage and co, but I'm
> interested in ways of making this easier. Before I give this more thought, I'd
> be interested to know if anyone has already got any scripts or tips :)

Abuse the cvs eclass, and write an ebuild that does a co itself.  If 
you're after basically having the unpack func switchable (are we cvs 
based, or are we working from a known tarball)... yeah, eww. :)
~brian
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Gentoo as a development platform

[Daniel Drake]

Brian Harring wrote:
> [...] and write an ebuild [...]

I'm thinking in terms of making things as easy as possible. I'd rather not
have to go to the effort of writing an ebuild for every package (and maybe
some of its deps) that I want to hack on.

> If 
> you're after basically having the unpack func switchable (are we cvs 
> based, or are we working from a known tarball)... yeah, eww. :)

Yep - it's probably not going to be a clean solution, at least for now. But if
I can get something that vaguely works then it will be a big timesaver. In the
example I used there, we already have the ebuild code designed to build the
sources and install the package. And I have the code right here on my disk.
I'd like it to be possible to combine the two with minimum effort involved.

The switching-source thing was just one example. Here's a couple of other
things that have crossed my mind:

- I'm manually configuring a package that I want installed in ebuild-fashion.
I know when an ebuild runs econf it passes many configure parameters to
achieve this (installation into /var/tmp, etc.). It would be nice if I could
just run "econf" from the command line and still achieve this. Similarly for
emake. Then I can somehow tell portage I've done src_unpack and src_compile
manually, so I'd just like it to get on from src_install onwards.

- I've just compiled/installed a package from an ebuild in a semi-automatic
fashion. I made a mistake in one of the functions. I change one line of code
which is an obvious fix. I now want that to take effect on my live filesystem,
 so I want to recompile (without re-running ./configure as that would slow me
down) only the bits that have changed (ala make) and then reinstall.
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Gentoo as a development platform

[Donnie Berkholz]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Daniel Drake wrote:
> - I'm manually configuring a package that I want installed in ebuild-fashion.
> I know when an ebuild runs econf it passes many configure parameters to
> achieve this (installation into /var/tmp, etc.). It would be nice if I could
> just run "econf" from the command line and still achieve this. Similarly for
> emake. Then I can somehow tell portage I've done src_unpack and src_compile
> manually, so I'd just like it to get on from src_install onwards.

You could source whatever files contain those functions, and create the
files telling portage it's finished certain steps. I think there's a
.compiled, not sure about others.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFCYb5dXVaO67S1rtsRArujAJ4nlXgiFB9CAW5vW8Z2pni0iOs0fwCgrK7s
0XKUwl/jBNyvTr2wv6Tvc94=
=smnj
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Gentoo as a development platform

[Brian Harring]

On Sat, Apr 16, 2005 at 06:39:41PM -0700, Donnie Berkholz wrote:
> Daniel Drake wrote:
> > - I'm manually configuring a package that I want installed in ebuild-fashion.
> > I know when an ebuild runs econf it passes many configure parameters to
> > achieve this (installation into /var/tmp, etc.). It would be nice if I could
> > just run "econf" from the command line and still achieve this. Similarly for
> > emake. Then I can somehow tell portage I've done src_unpack and src_compile
> > manually, so I'd just like it to get on from src_install onwards.
> 
> You could source whatever files contain those functions, and create the
> files telling portage it's finished certain steps. I think there's a
> .compiled, not sure about others.

You want an ebuild shell, basically?  Akin to sandbox shell?

Via cvs head of portage (doesn't work without a bit o hackery for 
stable)

http://dev.gentoo.org/~ferringb/ebuild-env
http://dev.gentoo.org/~ferringb/ebuild.bashrc

Give you such a shell.
Details are at http://dev.gentoo.org/~ferringb/blog/archives/2005-03.html#e2005-03-09T04_43_49.txt
~brian
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Gentoo as a development platform

[Jason Cooper]

Daniel Drake (dsd@gentoo.org) scribbled:
> Quite often, I use Gentoo's from-source nature to my advantage when developing
> or testing software packages.
> 
> Gentoo is fairly well oriented for this kind of environment, but it's not
> brilliant. As an example, foo-3.2.1 (the latest version) is installed on my
> system, but more recently, they fixed a critical bug in the upstream CVS tree
> which I'd like to test the fix for. It's not dead simple for me to do this - I
> want to use the CVS sources with the ebuild already in portage. I have to use
> "ebuild foo-3.2.1.ebuild unpack" to extract the sources, then manually replace
> them with my CVS checkout. Or checkout CVS, make a new tarball, call it
> foo-3.2.1.tar.bz2, redigest and remerge the ebuild. Or I could create a
> foo-cvs ebuild and go to the trouble of making it mirror the contents of
> foo-3.2.1.ebuild exactly.
> 
> It's great that its *possible* right now thanks to portage and co, but I'm
> interested in ways of making this easier. Before I give this more thought, I'd
> be interested to know if anyone has already got any scripts or tips :)

What about something akin to gcc?  ie. you create a
/usr/local/portage/foo-ness/foo/foo-cvs.ebuild, then adapt gcc-config to
select which installed package to use, foo-1.2.3 or foo-cvs?  Would
definitely be some work, but would be a good long-term, easily
maintainable solution.  'foo-config cvs' would use the last cvs build
you did, then 'foo-config 1.2.3' would drop you back to regular.

hth,

Cooper.
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Gentoo as a development platform

[Brian Harring]

On Sun, Apr 17, 2005 at 12:36:19AM +0100, Daniel Drake wrote:
> Hi,
> 
> Quite often, I use Gentoo's from-source nature to my advantage when developing
> or testing software packages.
> 
> Gentoo is fairly well oriented for this kind of environment, but it's not
> brilliant. As an example, foo-3.2.1 (the latest version) is installed on my
> system, but more recently, they fixed a critical bug in the upstream CVS tree
> which I'd like to test the fix for. It's not dead simple for me to do this - I
> want to use the CVS sources with the ebuild already in portage. I have to use
> "ebuild foo-3.2.1.ebuild unpack" to extract the sources, then manually replace
> them with my CVS checkout. Or checkout CVS, make a new tarball, call it
> foo-3.2.1.tar.bz2, redigest and remerge the ebuild. Or I could create a
> foo-cvs ebuild and go to the trouble of making it mirror the contents of
> foo-3.2.1.ebuild exactly.
Tarball up the snapshot, ensure the ebuild relies on $PV for 
discerning what tarball to unpack (src_uri="http://download.berlios.de/${PN}/${PF}.tar.bz2" fex)
and all you have to do is rename the ebuild to the snapshot tag....
~brian
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Gentoo as a development platform

[Donnie Berkholz]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Daniel Drake wrote:
> Gentoo is fairly well oriented for this kind of environment, but it's not
> brilliant. As an example, foo-3.2.1 (the latest version) is installed on my
> system, but more recently, they fixed a critical bug in the upstream CVS tree
> which I'd like to test the fix for. It's not dead simple for me to do this - I
> want to use the CVS sources with the ebuild already in portage. I have to use
> "ebuild foo-3.2.1.ebuild unpack" to extract the sources, then manually replace
> them with my CVS checkout. Or checkout CVS, make a new tarball, call it
> foo-3.2.1.tar.bz2, redigest and remerge the ebuild. Or I could create a
> foo-cvs ebuild and go to the trouble of making it mirror the contents of
> foo-3.2.1.ebuild exactly.

I generally just bump the version of a current ebuild to reflect a dated
tarball that's a CVS snapshot, e.g. foo-3.2.1_p20050416 or foo-20050416.

Then do FEATURES=digest emerge foo, and it'll create the digest for ya
and update.

Carefully combined with FEATURES like keeptemp and keepwork, this could
do nearly what you suggest.

Using the same exact ebuild for multiple versions seems like a recipe
for disaster.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFCYb4UXVaO67S1rtsRAnQWAJoCHQXAQ4rEhAAL/UvJhwVQEJp02gCfTUbE
N4D9t1unZuXNkPfuLoa/jNI=
=5tYo
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list