[gentoo-dev] New darcs.eclass

[gentoo-dev] New darcs.eclass

[Duncan Coutts]

In case anyone needs distracting from a current hot topic...

Just like we have eclasses for cvs, tla etc, kosmikus has written one
that does the same thing but for darcs.

Darcs (dev-util/darcs) is one of the new breed of distributed source
control systems. Many projects are now maintaining their development
sources in darcs, hence the utility of this eclass:

http://haskell.org/~gentoo/gentoo-haskell/portage/eclass/darcs.eclass

kosmikus adapted it from the cvs and tla eclasses. We've been using it
for some time in the Haskell team's overlay and we've had a request to
include it in the main tree.

http://bugs.gentoo.org/show_bug.cgi?id=128307
That request includes an implementation but we're proposing our own
implementation that is a bit more sophisticated and has already been
tested with a few *-darcs ebuilds.

So we'd like to have people's opinion/comments on this going into the
tree and of course we would appreciate code review etc.

-- 
Duncan Coutts : Gentoo Developer (Haskell team lead)
email         : dcoutts at gentoo dot org

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] New git.eclass

[Donnie Berkholz]

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

Duncan Coutts wrote:
> In case anyone needs distracting from a current hot topic...
> 
> Just like we have eclasses for cvs, tla etc, kosmikus has written one
> that does the same thing but for darcs.

s/kosmikus has/I have/, s/darcs/git/

> Darcs (dev-util/darcs) is one of the new breed of distributed source

s/Darcs (dev-util/darcs)/Git (dev-util/git)

> control systems. Many projects are now maintaining their development
> sources in darcs, hence the utility of this eclass:

s/darcs/git/

Available in my overlay [1] and used in libX11-9999 and cairo-9999.

Thanks,
Donnie

1. http://dev.gentoo.org/~spyderous/overlay/


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: [gentoo-dev] New git.eclass

[Fernando J. Pereda]

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

On Thu, May 18, 2006 at 06:30:47PM -0700, Donnie Berkholz wrote:
> [snip]

Hi,

I think I improved the eclass a bit by making it more efficient both
disk and network wise among other things:

-  Branchs are supported so different versions of the ebuild can use
   different versions of the code without duplicating objects.

-  Once you cloned the first time, following installations only fetch
   updates for the branch you are going to use.

-  It clones a 'bare' repository, i.e. without a working copy, thus
   saving disk space.

-  Uses 'git tar-tree' instead of 'rsync' to checkout a particular
   commitish (EGIT_TREE).

-  It is able to repack and prune the repository to save disk space and
   improve performance. Ebuilds can override this behavior by setting
   EGIT_{PRUNE,REPACK} to false.

I also bash'ified the eclass, I don't know if this is a good thing but
makes things easier to read (at least for me). Everything should work
perfectly on bash2 systems.

I'd like people who use Git eclass to test it and see if any of the
'features' I introduced break things for them.

Also, git-sources *should* use this eclass once it is in the tree since
people using it will save _lots_ of bandwidth and disk space.

Latest version is in my public overlay[1].

- ferdy

[1] http://dev.gentoo.org/~ferdy/overlay/eclass/git.eclass

-- 
Fernando J. Pereda Garcimartín
Gentoo Developer (Alpha,net-mail,mutt,git)
20BB BDC3 761A 4781 E6ED  ED0B 0A48 5B0C 60BD 28D4

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

Re: [gentoo-dev] New git.eclass

[Greg KH]

On Fri, May 19, 2006 at 01:45:30PM +0200, Fernando J. Pereda wrote:
> Also, git-sources *should* use this eclass once it is in the tree since
> people using it will save _lots_ of bandwidth and disk space.

Yes, I'll convert it over once you feel it is ready, just let me know.

thanks,

greg k-h
-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: New darcs.eclass

[Stefan Schweizer]

There is also a darcs.eclass in the zugaina overlay (available through
layman) if you need some more inspiration.

I think this is cool and a darcs eclass should definitely live in the tree.
Please add it, so that we can start using it :)

- Stefan

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] New git.eclass

[Robin H. Johnson]

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

On Fri, May 19, 2006 at 09:08:08AM -0700, Greg KH wrote:
> On Fri, May 19, 2006 at 01:45:30PM +0200, Fernando J. Pereda wrote:
> > Also, git-sources *should* use this eclass once it is in the tree since
> > people using it will save _lots_ of bandwidth and disk space.
> Yes, I'll convert it over once you feel it is ready, just let me know.
I'd like to voice an objection to converting git-sources using a
git.eclass and performing live fetching.

This takes away the ability to use to existing git snapshots when there
is no or minimal network connectivity.

I don't object to it being in addition to the existing snapshot mode,
but please don't take the snapshot mode away.

-- 
Robin Hugh Johnson
E-Mail     : robbat2@gentoo.org
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85

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

Re: [gentoo-dev] New git.eclass

[Greg KH]

On Fri, May 19, 2006 at 02:18:05PM -0700, Robin H. Johnson wrote:
> On Fri, May 19, 2006 at 09:08:08AM -0700, Greg KH wrote:
> > On Fri, May 19, 2006 at 01:45:30PM +0200, Fernando J. Pereda wrote:
> > > Also, git-sources *should* use this eclass once it is in the tree since
> > > people using it will save _lots_ of bandwidth and disk space.
> > Yes, I'll convert it over once you feel it is ready, just let me know.
> I'd like to voice an objection to converting git-sources using a
> git.eclass and performing live fetching.
> 
> This takes away the ability to use to existing git snapshots when there
> is no or minimal network connectivity.
> 
> I don't object to it being in addition to the existing snapshot mode,
> but please don't take the snapshot mode away.

Ok, we'll make it a new ebuild.  "git-live-sources" perhaps?  :)

thanks,

greg k-h
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] New git.eclass

[Donnie Berkholz]

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

Robin H. Johnson wrote:
> On Fri, May 19, 2006 at 09:08:08AM -0700, Greg KH wrote:
>> On Fri, May 19, 2006 at 01:45:30PM +0200, Fernando J. Pereda wrote:
>>> Also, git-sources *should* use this eclass once it is in the tree since
>>> people using it will save _lots_ of bandwidth and disk space.
>> Yes, I'll convert it over once you feel it is ready, just let me know.
> I'd like to voice an objection to converting git-sources using a
> git.eclass and performing live fetching.
> 
> This takes away the ability to use to existing git snapshots when there
> is no or minimal network connectivity.

I'm not sure I understand. If you have enough connectivity to get a
snapshot to the machine, why wouldn't you have enough to get a .git/ to it?

Thanks,
Donnie


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: [gentoo-dev] New git.eclass

[Donnie Berkholz]

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

Greg KH wrote:
> Ok, we'll make it a new ebuild.  "git-live-sources" perhaps?  :)

If you just want the latest git rather than snapshots etc, you could do
a git-sources-9999.ebuild. That seems to have become the standard.

Thanks,
Donnie


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: [gentoo-dev] New git.eclass

[Robin H. Johnson]

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

On Fri, May 19, 2006 at 02:32:13PM -0700, Donnie Berkholz wrote:
> Robin H. Johnson wrote:
> > On Fri, May 19, 2006 at 09:08:08AM -0700, Greg KH wrote:
> >> On Fri, May 19, 2006 at 01:45:30PM +0200, Fernando J. Pereda wrote:
> >>> Also, git-sources *should* use this eclass once it is in the tree since
> >>> people using it will save _lots_ of bandwidth and disk space.
> >> Yes, I'll convert it over once you feel it is ready, just let me know.
> > I'd like to voice an objection to converting git-sources using a
> > git.eclass and performing live fetching.
> > 
> > This takes away the ability to use to existing git snapshots when there
> > is no or minimal network connectivity.
> 
> I'm not sure I understand. If you have enough connectivity to get a
> snapshot to the machine, why wouldn't you have enough to get a .git/ to it?
Simple case - consider a disconnected machine, that you use sneakernet
to get files to - I've had a few in the past where the hardware was new
enough that networking was broken or not supported yet, and I had to try
a few patches and snapshots before actually getting it to work.

Another case might be a machine where HTTP/FTP access is allowed out via
a filter proxy, but not anything else (I've had a few cases like this in
doing Gentoo consulting).

-- 
Robin Hugh Johnson
E-Mail     : robbat2@gentoo.org
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85

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

Re: [gentoo-dev] New git.eclass

[Donnie Berkholz]

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

Robin H. Johnson wrote:
> Simple case - consider a disconnected machine, that you use sneakernet
> to get files to - I've had a few in the past where the hardware was new
> enough that networking was broken or not supported yet, and I had to try
> a few patches and snapshots before actually getting it to work.

I don't see much of an effective difference here. Both ways you've gotta
burn files to disk and copy 'em over.

> Another case might be a machine where HTTP/FTP access is allowed out via
> a filter proxy, but not anything else (I've had a few cases like this in
> doing Gentoo consulting).

git clone
http://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git

Thanks,
Donnie


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: [gentoo-dev] New git.eclass

[Diego 'Flameeyes' Pettenò]

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

On Friday 19 May 2006 23:44, Donnie Berkholz wrote:
> If you just want the latest git rather than snapshots etc, you could do
> a git-sources-9999.ebuild. That seems to have become the standard.
I would suggest a 2.6.999 just to be on the safe side ;)

-- 
Diego "Flameeyes" Pettenò - http://farragut.flameeyes.is-a-geek.org/
Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE

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

Re: [gentoo-dev] New darcs.eclass

[Aron Griffis]

Along these lines, I added my mercurial.eclass to the tree.  I use it
personally for a couple projects, and figured it might help prevent
other people from needing to re-invent the wheel.

Regards,
Aron
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] New git.eclass

[Donnie Berkholz]

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

Fernando J. Pereda wrote:
> I'd like people who use Git eclass to test it and see if any of the
> 'features' I introduced break things for them.

I just incorporated much of this into my version (minus some whitespace
changes) and pushed it up. Seems to work fine on my stuff, although the
additional time taken by the repack and prune is mildly annoying,
particularly considering the point of git is to be fast at the cost of
disk space rather than vice versa. =)

Thanks,
Donnie


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: [gentoo-dev] New darcs.eclass

[Henrik Brix Andersen]

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

On Fri, May 19, 2006 at 10:36:42PM -0400, Aron Griffis wrote:
> Along these lines, I added my mercurial.eclass to the tree.  I use it
> personally for a couple projects, and figured it might help prevent
> other people from needing to re-invent the wheel.

Errr... you added a new eclass without posting it to this mailing list
for review first?

./Brix
-- 
Henrik Brix Andersen <brix@gentoo.org>
Gentoo Metadistribution | Mobile computing herd

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

Re: [gentoo-dev] New darcs.eclass

[Aron Griffis]

Henrik Brix Andersen wrote: [Sat May 20 2006, 04:50:22AM EDT]
> On Fri, May 19, 2006 at 10:36:42PM -0400, Aron Griffis wrote:
> > Along these lines, I added my mercurial.eclass to the tree.  I use it
> > personally for a couple projects, and figured it might help prevent
> > other people from needing to re-invent the wheel.
> 
> Errr... you added a new eclass without posting it to this mailing
> list for review first?

I've never posted an eclass here for review, and I don't think I've
ever announced one before either, so let's call this progress. ;-)

If you'd like to review it, I'd appreciate the input.

Thanks,
Aron

-- 
gentoo-dev@gentoo.org mailing list

Re: mercurial.eclass (was: [gentoo-dev] New darcs.eclass)

[Matthias Schwarzott]

On Saturday 20 May 2006 15:23, Aron Griffis wrote:
> Henrik Brix Andersen wrote: [Sat May 20 2006, 04:50:22AM EDT]
>
> > On Fri, May 19, 2006 at 10:36:42PM -0400, Aron Griffis wrote:
> > > Along these lines, I added my mercurial.eclass to the tree.  I use it
> > > personally for a couple projects, and figured it might help prevent
> > > other people from needing to re-invent the wheel.
> >
> > Errr... you added a new eclass without posting it to this mailing
> > list for review first?
>
> I've never posted an eclass here for review, and I don't think I've
> ever announced one before either, so let's call this progress. ;-)
>
> If you'd like to review it, I'd appreciate the input.
>

I am in the process of creating the ebuild v4l-dvb-hg to compile the sources 
for the development-dvb-driver.

I have a few annotations for mercurial.eclass:
* The eclass copies the downloaded sources to ${S} rather than to 
${WORKDIR}/${HG_MODULE_NAME}.
So I have to use
S=${WORKDIR}/xyz to unpack it there and have S set to a subdirectory of the 
hg-sources.

* the unpack-function keeps the current working directory 
in /usr/portage/distfiles/hg-src/${HG_MODULE}.
That creates problems when applying patches.
Could the eclass switch to ${WORKDIR} after unpacking.


Now I use this part of code

S=${WORKDIR}/v4l-dvb/v4l
src_unpack() {
    S=${WORKDIR}/v4l-dvb mercurial_src_unpack
    cd ${WORKDIR}
    epatch ...
}

Regards
  Matthias

-- 
Matthias Schwarzott
Gentoo Developer
http://www.gentoo.org
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] New git.eclass

[Fernando J. Pereda]

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

On Fri, May 19, 2006 at 11:58:32PM -0700, Donnie Berkholz wrote:
> Fernando J. Pereda wrote:
> > I'd like people who use Git eclass to test it and see if any of the
> > 'features' I introduced break things for them.
> 
> I just incorporated much of this into my version (minus some whitespace
> changes) and pushed it up. Seems to work fine on my stuff, although the
> additional time taken by the repack and prune is mildly annoying,
> particularly considering the point of git is to be fast at the cost of
> disk space rather than vice versa. =)

We could make EGIT_PRUNE and EGIT_REPACK to default to 'false' then.

Is there a way users could set these variables and choose if they want
to prune/repack or not ?

Cheers

- ferdy

-- 
Fernando J. Pereda Garcimartín
Gentoo Developer (Alpha,net-mail,mutt,git)
20BB BDC3 761A 4781 E6ED  ED0B 0A48 5B0C 60BD 28D4

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

Re: [gentoo-dev] New darcs.eclass

[Duncan Coutts]

Since there were no objections the darcs.eclass is now in the main tree.

On Thu, 2006-05-18 at 22:58 +0100, Duncan Coutts wrote:
> Just like we have eclasses for cvs, tla etc, kosmikus has written one
> that does the same thing but for darcs.
> 
> Darcs (dev-util/darcs) is one of the new breed of distributed source
> control systems. Many projects are now maintaining their development
> sources in darcs, hence the utility of this eclass:
> 
> http://haskell.org/~gentoo/gentoo-haskell/portage/eclass/darcs.eclass
> 
> kosmikus adapted it from the cvs and tla eclasses. We've been using it
> for some time in the Haskell team's overlay and we've had a request to
> include it in the main tree.
> 
> http://bugs.gentoo.org/show_bug.cgi?id=128307
> That request includes an implementation but we're proposing our own
> implementation that is a bit more sophisticated and has already been
> tested with a few *-darcs ebuilds.
> 
> So we'd like to have people's opinion/comments on this going into the
> tree and of course we would appreciate code review etc.

-- 
Duncan Coutts : Gentoo Developer (Haskell team lead)
email         : dcoutts at gentoo dot org

-- 
gentoo-dev@gentoo.org mailing list

Re: mercurial.eclass (was: [gentoo-dev] New darcs.eclass)

[Aron Griffis]

Matthias,

Matthias Schwarzott wrote:  [Sun May 21 2006, 05:40:53AM EDT]
> * The eclass copies the downloaded sources to ${S} rather than to 
> ${WORKDIR}/${HG_MODULE_NAME}.
> * the unpack-function keeps the current working directory 
> in /usr/portage/distfiles/hg-src/${HG_MODULE}.

Could you try the version from my (new and shiny) overlay?

    http://n01se.net/agriffis/overlay/

I think this solves both problems.  I didn't create a variable
HG_MODULE_NAME because with mercurial the name of the module is always
the last component of the URL.  

I don't think for your purposes it matters, but you can rename the
local clone by calling mercurial_fetch directly, for example:

    mercurial_fetch http://n01se.net/agriffis/overlay overlay_agriffis

Regards,
Aron
-- 
gentoo-dev@gentoo.org mailing list

Re: mercurial.eclass (was: [gentoo-dev] New darcs.eclass)

[Matthias Schwarzott]

On Wednesday 24 May 2006 03:30, Aron Griffis wrote:
> Matthias,
>
> Matthias Schwarzott wrote:  [Sun May 21 2006, 05:40:53AM EDT]
>
> > * The eclass copies the downloaded sources to ${S} rather than to
> > ${WORKDIR}/${HG_MODULE_NAME}.
> > * the unpack-function keeps the current working directory
> > in /usr/portage/distfiles/hg-src/${HG_MODULE}.
>
> Could you try the version from my (new and shiny) overlay?
>
>     http://n01se.net/agriffis/overlay/
>
> I think this solves both problems.  I didn't create a variable
> HG_MODULE_NAME because with mercurial the name of the module is always
> the last component of the URL.
>
> I don't think for your purposes it matters, but you can rename the
> local clone by calling mercurial_fetch directly, for example:
>
>     mercurial_fetch http://n01se.net/agriffis/overlay overlay_agriffis
>

I checked the version from your overlay, and it works like before and also 
solves the mentioned problems.

Matthias

-- 
Matthias Schwarzott
Gentoo Developer
http://www.gentoo.org
-- 
gentoo-dev@gentoo.org mailing list