[gentoo-user] modifying locally an ebuild

[gentoo-user] modifying locally an ebuild

[Fernando Canizo]

Hi all, 

I find a cute patch to mutt and to use it i modified the ebuild and
the pertinent files so now re-emerging mutt builds mutt with this
patch. Later i fixed the actual version of mutt so an upgrade cannot
erase it.

What i would like to know is how can i do this i a 'gentoo way'. I
have listen that there are something called SLOTs, but never used so
far (never need them?)

Or the only way is to propose the add of the patch to portage?

-- 
Fernando Canizo - http://www.lugmen.org.ar/~conan/
Hatred, n.:
	A sentiment appropriate to the occasion of another's superiority.
		-- Ambrose Bierce, "The Devil's Dictionary"
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] modifying locally an ebuild

[Holly Bostick]

Fernando Canizo schreef:
> Hi all, 
> 
> I find a cute patch to mutt and to use it i modified the ebuild and
> the pertinent files so now re-emerging mutt builds mutt with this
> patch. Later i fixed the actual version of mutt so an upgrade cannot
> erase it.
> 
> What i would like to know is how can i do this i a 'gentoo way'. I
> have listen that there are something called SLOTs, but never used so
> far (never need them?)
> 
> Or the only way is to propose the add of the patch to portage?
> 

Normally what one would do is place all modified ebuilds in your
PORTDIR_OVERLAY (Portage directory overlay), which location can be set
in /etc/make.conf (default is /usr/local/portage).

/usr/local/portage has the same structure as the 'normal' portage tree,
meaning that your ebuild would need to be placed in
/usr/local/portage/mail-client/mutt/mutt-whatever.ebuild, and the
currently-existing patch files would need to be copied to
/usr/local/portage/mail-client/mutt/files, along with your additional patch.

You would then use the command

ebuild /usr/local/portage/mail-client/mutt/mutt-whatever.ebuild digest

to create the manifest file (so that Portage knows what files are
associated with the ebuild, and can calculate their MD5 sums to check
them for corruption when emerging).

At that point, because your ebuild is newer than the one in Portage,
when you emerge mutt, your overlay ebuild is considered most recent, and
you will see it when you attempt to emerge as follows (this example  of
course uses a different ebuild because mutt isn't in my overlay):

emerge -pv unace
________________________________________________________________________________

cfg-update 1.7.1 : Building checksum index... (takes a few seconds)  done!
________________________________________________________________________________


These are the packages that I would merge, in order:

Calculating dependencies ...done!
[ebuild   R   ] app-arch/unace-2.2  178 kB [1]

Total size of downloads: 178 kB
Portage overlays:
 [1] /usr/local/portage
 [2] /usr/local/bmg-main

As you see, the emerge data is footnoted with a [1], and the legend says
that the ebuild comes from my first overlay, in /usr/local/portage.

The thing is, that ebuilds in your overlay aren't overwritten or touched
in any way by Portage, so you don't have to keep 'redoing' the ebuild
every time you emerge sync.

If the ebuild in Portage hasn't changed, your modified ebuild will
always be newer; if the ebuild in Portage has changed, it's quite likely
that whatever patch or functionality you were waiting for has been
merged into the main tree upstream, or backported into the ebuild, so
you have an easy migration path back into main Portage (and of course,
if you care enough about the application and its patchset to modify an
ebuild and put it in your overlay, checking the ChangeLog of any updated
ebuilds is not an onerous task).

If the program has been updated, but your patch still isn't there, then
you can just copy and modify the updated ebuild and files.

So that's the userland solution, but yes, if you want the patch included
in Portage (which is likely to happen anyway, if it's a patch from
upstream), the place to submit it for inclusion (preferably with the
modified ebuild attached as well), would be bugs.gentoo.org (b.g.o).
That's where most of the ebuilds in my overlay come from :) .

The nice things about submitting the modified ebuild in this way are that

1) it makes less work for the devs (they don't have to write the ebuild,
only check/correct yours);

2) if for some reason they are delayed in, or don't want to, include the
ebuild into Portage (as is the case with the unace ebuild in the example
above), it's still available for those crazy or desperate enough to want
to use it anyway.

3) it helps people willing to debug to do so-- I'm fairly sure that
those of us who contributed to debugging the taskjuggler ebuild helped
the ebuild become better, faster, so that it was recently included in
Portage (though I can't compile it for some reason, gotta revisit that
bug, actually).

Hope that helps answer your question.
Holly
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] modifying locally an ebuild

[Nick Rout]

On Wed, 31 Aug 2005 03:36:57 +0200
Holly Bostick wrote:

> Fernando Canizo schreef:
> > Hi all, 
> > 
> > I find a cute patch to mutt and to use it i modified the ebuild and
> > the pertinent files so now re-emerging mutt builds mutt with this
> > patch. Later i fixed the actual version of mutt so an upgrade cannot
> > erase it.
> > 
> > What i would like to know is how can i do this i a 'gentoo way'. I
> > have listen that there are something called SLOTs, but never used so
> > far (never need them?)
> > 
> > Or the only way is to propose the add of the patch to portage?
> > 
> 
[snip]
> 
> If the ebuild in Portage hasn't changed, your modified ebuild will
> always be newer; if the ebuild in Portage has changed, it's quite likely
> that whatever patch or functionality you were waiting for has been
> merged into the main tree upstream, or backported into the ebuild, so
> you have an easy migration path back into main Portage (and of course,
> if you care enough about the application and its patchset to modify an
> ebuild and put it in your overlay, checking the ChangeLog of any updated
> ebuilds is not an onerous task).
> 
> If the program has been updated, but your patch still isn't there, then
> you can just copy and modify the updated ebuild and files.
> 
[snip]

Good post Holly, you should make it into a howto.

2 things spring to mind:

1. i thought that overlay always beats normal portage, but you are
saying newer ebuild file wins (ie if the official ebuild has been
updated but not renamed it will beat what is in overlay. ) - do you have
any reference for that (I sure don't, its just how I thought it worked)

2. Fernando might like to note that the way to introduce a patch to a
package (rather than an amendment to the ebuild) is to use the epatch
command. Commonly the line looks like this:

epatch ${FILESDIR}/cool-all-mutt.patch

In that case the patch is in the files directory below the ebuild file.

If the patch is large or publicly available, you are better NOT to put
it in the portage tree but have it downloaded from a mirror with e
SRC_URI command. If you want an example of this take a look at the
vlc-0.8.2-r1 ebuild (chosen by me cos I was unsuccessfully hacking it
the other day)

> -- 
> gentoo-user@gentoo.org mailing list

-- 
Nick Rout <nick@rout.co.nz>

-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] modifying locally an ebuild

[Fernando Canizo]

El 31/ago/2005 a las 00:23 -0300, Nick me decía:
> 2. Fernando might like to note that the way to introduce a patch to a
> package (rather than an amendment to the ebuild) is to use the epatch
> command. Commonly the line looks like this:

You're saying that i can emerge mutt, run epatch command and then
re-emerge and assumes the patch? It sounds crazy for me, maybe i don't
understand.

> epatch ${FILESDIR}/cool-all-mutt.patch

I see that command in ebuilds, but where is it? I can't find it in my
installation, but somewhere must be since it gets used.

> If the patch is large or publicly available, you are better NOT to put
> it in the portage tree but have it downloaded from a mirror with e
> SRC_URI command. If you want an example of this take a look at the
> vlc-0.8.2-r1 ebuild (chosen by me cos I was unsuccessfully hacking it
> the other day)
 
I don't understand this either, if i put something un *my* portage
tree the mirrors get infested?

(hum... better get some sleep now, i'm understanding less after each
minute)

-- 
Fernando Canizo - http://www.lugmen.org.ar/~conan/
lighthouse, n.:
	A tall building on the seashore in which the government
	maintains a lamp and the friend of a politician.
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] modifying locally an ebuild

[Nick Rout]

On Wed, 2005-08-31 at 02:56 -0300, Fernando Canizo wrote:
> El 31/ago/2005 a las 00:23 -0300, Nick me decía:
> > 2. Fernando might like to note that the way to introduce a patch to a
> > package (rather than an amendment to the ebuild) is to use the epatch
> > command. Commonly the line looks like this:
> 
> You're saying that i can emerge mutt, run epatch command and then
> re-emerge and assumes the patch? It sounds crazy for me, maybe i don't
> understand.

no no, you put the epatch command in your ebuild file (your own version
that you put in PORTAGE_OVERLAY.)  Then the patch gets applied to the
mutt source file before compilation.

> 
> > epatch ${FILESDIR}/cool-all-mutt.patch
> 
> I see that command in ebuilds, but where is it? I can't find it in my
> installation, but somewhere must be since it gets used.
> 

epatch is internal to portage, it is the gentoo version of the patch
command. If you want to see some examples look in portage, eg:

grep epatch /usr/portage/* -r


> > If the patch is large or publicly available, you are better NOT to put
> > it in the portage tree but have it downloaded from a mirror with e
> > SRC_URI command. If you want an example of this take a look at the
> > vlc-0.8.2-r1 ebuild (chosen by me cos I was unsuccessfully hacking it
> > the other day)
>  
> I don't understand this either, if i put something un *my* portage
> tree the mirrors get infested?
> 

no. lets start again.

there are two places that portage can get the patch from. 


1. If it is small you can put it in ${FILESDIR} which is, in our case:

/usr/local/portage/mail-client/mutt/files/cool-all-mutt.patch

Then it is only on your system. If your revised ebuild gets accepted
into portage then the patch file will also get in the portage tree and
every gentooista will eventually get it via emerge sync.

2. If it is large, or if it is, for example, a commonly available public
patch (for example that some third party has published) then you can
instruct portage to download it from the net by specifying a SRC_URI,
viz:

SRC_URI="http://some.place.net/pub/patches/mutt/cool-all-mutt.patch"


You can do that in your private OVERLAY ebuild, and as you say you found
the patch on the net, that may be the best way to do it.

Again, if your revised ebuild gets accepted and if the "powers that be"
get with it, the patch file might also get into the gentoo mirrors,
meaning that it is easier to get with more redundancy.

> (hum... better get some sleep now, i'm understanding less after each
> minute)
> 
> -- 
> Fernando Canizo - http://www.lugmen.org.ar/~conan/
> lighthouse, n.:
> 	A tall building on the seashore in which the government
> 	maintains a lamp and the friend of a politician.
-- 
Nick Rout <nick@rout.co.nz>

-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] modifying locally an ebuild

[Nagatoro]

For a _great_ place to read about ebuilds go to:
http://dev.gentoo.org/~plasmaroo/devmanual/

It has next to everything :)
-- 
Naga
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] modifying locally an ebuild

[Fernando Canizo]

El 31/ago/2005 a las 03:37 -0300, Nick me decía:
> no no, you put the epatch command in your ebuild file (your own version
> that you put in PORTAGE_OVERLAY.)  Then the patch gets applied to the
> mutt source file before compilation.

Ah... Already did that! In my modified ebuild what i did was to copy
lines from other patches and then adecuate them.

> > I don't understand this either, if i put something un *my* portage
> > tree the mirrors get infested?
> > 
> 
> no. lets start again.
> 
> there are two places that portage can get the patch from. 
> 
> 
> 1. If it is small you can put it in ${FILESDIR} which is, in our case:
> 
> /usr/local/portage/mail-client/mutt/files/cool-all-mutt.patch
> 
> Then it is only on your system. If your revised ebuild gets accepted
> into portage then the patch file will also get in the portage tree and
> every gentooista will eventually get it via emerge sync.
> 
> 2. If it is large, or if it is, for example, a commonly available public
> patch (for example that some third party has published) then you can
> instruct portage to download it from the net by specifying a SRC_URI,
> viz:
> 
> SRC_URI="http://some.place.net/pub/patches/mutt/cool-all-mutt.patch"
> 
> 
> You can do that in your private OVERLAY ebuild, and as you say you found
> the patch on the net, that may be the best way to do it.

Cool, that's what i'll do.

> Again, if your revised ebuild gets accepted and if the "powers that be"
> get with it, the patch file might also get into the gentoo mirrors,
> meaning that it is easier to get with more redundancy.
 
I'm gonna try to file the bug report asking for it to be in portage
this afternoon. (got to go running now)

-- 
Fernando Canizo - http://www.lugmen.org.ar/~conan/
QOTD:
	"I drive my car quietly, for it goes without saying."
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] modifying locally an ebuild

[Fernando Canizo]

El 30/ago/2005 a las 22:36 -0300, Holly me decía:
> Normally what one would do is place all modified ebuilds in your
> PORTDIR_OVERLAY ...

Thank you very much. You should take advice from Nick and make it a howto. I'm
surely going to translate to spanish and put it in my blog, maybe i would add
something if i get to make it work ;) 

I can't make it work but it's after 2 AM and maybe i just need to read some
docs.

ebuild says:

# ebuild /usr/local/portage/mail-client/mutt/mutt-conan-1.5.8-r2.ebuild digest
!!! aux_get(): ebuild path for 'mail-client/mutt-conan-1.5.8-r2' not specified:
!!!            None
!!! aux_get(): ebuild path for 'mail-client/mutt-conan-1.5.8-r2' not specified:
!!!            None
doebuild(): aux_get() error reading mail-client/mutt-conan-1.5.8-r2; aborting.

> to create the manifest file (so that Portage knows what files are
> associated with the ebuild, and can calculate their MD5 sums to check
> them for corruption when emerging).

I did it by hand, first time, when modified ebuild in /usr/portage

> The thing is, that ebuilds in your overlay aren't overwritten or touched
> in any way by Portage, so you don't have to keep 'redoing' the ebuild
> every time you emerge sync.

Cool, that's what i wanted. But i have to fix version in
/etc/portage/packages.mask if i want to forbid mutt being upgraded, have i?

> If the ebuild in Portage hasn't changed, your modified ebuild will
> always be newer; if the ebuild in Portage has changed, it's quite likely
> that whatever patch or functionality you were waiting for has been
> merged into the main tree upstream, or backported into the ebuild, so
> you have an easy migration path back into main Portage (and of course,
> if you care enough about the application and its patchset to modify an
> ebuild and put it in your overlay, checking the ChangeLog of any updated
> ebuilds is not an onerous task).

Well, i've not synced for a while, but i think sooner or later will do.
Emm... the patch isn't going to be upstream soon if ever. I asked for some
behaviour in mutt-user mailing list and someone give me this patch. Now i'm
asking there to put it in the core, but that could not happen.

> So that's the userland solution, but yes, if you want the patch included
> in Portage (which is likely to happen anyway, if it's a patch from
> upstream), the place to submit it for inclusion (preferably with the
> modified ebuild attached as well), would be bugs.gentoo.org (b.g.o).

Well, maybe i try it, the patch is so simple that even if never gets to mutt
core, i think it wouldn't do any damage to maintain it in gentoo. I can do that.

> Hope that helps answer your question.

Sure it does!

-- 
Fernando Canizo - http://www.lugmen.org.ar/~conan/
Renning's Maxim:
	Man is the highest animal.  Man does the classifying.
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] modifying locally an ebuild

[Holly Bostick]

Fernando Canizo schreef:
> El 30/ago/2005 a las 22:36 -0300, Holly me decía:
> 
>>Normally what one would do is place all modified ebuilds in your
>>PORTDIR_OVERLAY ...
> 
> 
> Thank you very much. You should take advice from Nick and make it a howto. I'm
> surely going to translate to spanish and put it in my blog, maybe i would add
> something if i get to make it work ;)

Thanks, and more power to you!

> 
> I can't make it work but it's after 2 AM and maybe i just need to read some
> docs.
> 
> ebuild says:
> 
> # ebuild /usr/local/portage/mail-client/mutt/mutt-conan-1.5.8-r2.ebuild digest
> !!! aux_get(): ebuild path for 'mail-client/mutt-conan-1.5.8-r2' not specified:
> !!!            None
> !!! aux_get(): ebuild path for 'mail-client/mutt-conan-1.5.8-r2' not specified:
> !!!            None
> doebuild(): aux_get() error reading mail-client/mutt-conan-1.5.8-r2; aborting.


The probelm here is (likely) that the name of the package (for the
purposes of the ebuild) is 'mutt-conan', not mutt.

The format for an overlay folder (like Portage) is

cat-egory/package-name/package-name.and-version.ebuild

so your ebuild should likely be in

/usr/local/portage/mail-client/mutt-conan/mutt-conan-1.5.8-r2.ebuild

rather than just 'mutt'.

I get caught by that one all the time

> 
> 
>>to create the manifest file (so that Portage knows what files are
>>associated with the ebuild, and can calculate their MD5 sums to check
>>them for corruption when emerging).
> 
> 
> I did it by hand, first time, when modified ebuild in /usr/portage
> 
> 
>>The thing is, that ebuilds in your overlay aren't overwritten or touched
>>in any way by Portage, so you don't have to keep 'redoing' the ebuild
>>every time you emerge sync.
> 
> 
> Cool, that's what i wanted. But i have to fix version in
> /etc/portage/packages.mask if i want to forbid mutt being upgraded, have i?

Not necessarily, because your package is called mutt-conan, not mutt. So
all you have to do is not emerge mutt-- as long as you don't emerge a
package that depends on mutt, which I don't know if there are any, you
should be good to go. If your package was called mutt, you could mask
all versions above the one you used, just like you would for any other
ebuild, but I wouldn't do that myself, because then how will you know if
the package was upgraded (possibly folding in your changes, or, if not,
nonetheless incorporating features that you might want in your modified
ebuild anyway). In other words, not masking the original package makes
it easier to know when to update your overlay ebuild, imo.

You might want to check your virtuals, though, and/or package.provided,
to let Portage know that "mutt" is provided by "mutt-conan".

> 
> 
>>If the ebuild in Portage hasn't changed, your modified ebuild will
>>always be newer; if the ebuild in Portage has changed, it's quite likely
>>that whatever patch or functionality you were waiting for has been
>>merged into the main tree upstream, or backported into the ebuild, so
>>you have an easy migration path back into main Portage (and of course,
>>if you care enough about the application and its patchset to modify an
>>ebuild and put it in your overlay, checking the ChangeLog of any updated
>>ebuilds is not an onerous task).
> 
> 
> Well, i've not synced for a while, but i think sooner or later will do.
> Emm... the patch isn't going to be upstream soon if ever. I asked for some
> behaviour in mutt-user mailing list and someone give me this patch. Now i'm
> asking there to put it in the core, but that could not happen.

Is this a behaviour that a significant portion of the mutt userbase
might want? Or are you just weird ;) ? If you're just weird, use your
overlay and be happy. If you think it might be useful to other mutt
users, submit it to b.g.o (make sure to explain the circumstances so
they don't go irritating upstream with a patch that upstream has no
interest in). Or, if there's an unofficial 'mutt users' site or two, you
could offer it to them to host, so that non-gentoo mutt users would have
access to it as well.

Or, if there's some way to 'modularize' mutt, you could look into
turning the patch into a 'plugin' (if such things exist, I know nothing
about mutt), so that it would be optional to those who wanted to use it.

> 
> 
>>So that's the userland solution, but yes, if you want the patch included
>>in Portage (which is likely to happen anyway, if it's a patch from
>>upstream), the place to submit it for inclusion (preferably with the
>>modified ebuild attached as well), would be bugs.gentoo.org (b.g.o).
> 
> 
> Well, maybe i try it, the patch is so simple that even if never gets to mutt
> core, i think it wouldn't do any damage to maintain it in gentoo. I can do that.

:) Yes, you can. Isn't Gentoo great? Did you know yesterday that "even
you" could contribute to development? $DEITY, I *love* that.... !

Holly
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] modifying locally an ebuild

[Neil Bothwick]

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

On Wed, 31 Aug 2005 13:39:04 +0200, Holly Bostick wrote:

> Or, if there's some way to 'modularize' mutt, you could look into
> turning the patch into a 'plugin' (if such things exist, I know nothing
> about mutt), so that it would be optional to those who wanted to use it.

Or you could add a USE flag, so the patch was only applied for those who
want it.


-- 
Neil Bothwick

without C people would code in Basi, Pasal and Obol

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

Re: [gentoo-user] modifying locally an ebuild

[Holly Bostick]

Neil Bothwick schreef:
> On Wed, 31 Aug 2005 13:39:04 +0200, Holly Bostick wrote:
> 
> 
>>Or, if there's some way to 'modularize' mutt, you could look into
>>turning the patch into a 'plugin' (if such things exist, I know nothing
>>about mutt), so that it would be optional to those who wanted to use it.
> 
> 
> Or you could add a USE flag, so the patch was only applied for those who
> want it.
> 
> 
I thought of that, but since I don't know what the patch is or does, I
didn't know if that would be appropriate. Though, come to think of it,
if there's local USE flags like GAPING_SECURITY_HOLE (forgot what ebuild
that's on, but saw it again yesterday during a light world update, makes
me laugh), or -insecure-drivers, I suppose that the patch could have its
own USE flag, no matter what it does.

But do you know the answer to Nick's question about what I said earlier?
In a 'conflict' between two ebuilds of the same name and version, one in
Portage and one in the overlay, does the choice of which one is used if
I emerge the relevant package rely on which one is most recent(ly
modified), or the location-- i.e., will the overlay ebuild always beat
the Portage ebuild even if the Portage build is newer (because it was
updated without changing the version number), or will the newer ebuild
always win out, whether it's in overlay or main Portage?

I think it's the latter, but I was tired when I wrote that, and offhand
don't remember where to look it up to verify.

Holly


-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] modifying locally an ebuild

[Neil Bothwick]

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

On Wed, 31 Aug 2005 14:42:16 +0200, Holly Bostick wrote:

> But do you know the answer to Nick's question about what I said earlier?
> In a 'conflict' between two ebuilds of the same name and version, one in
> Portage and one in the overlay, does the choice of which one is used if
> I emerge the relevant package rely on which one is most recent(ly
> modified), or the location-- i.e., will the overlay ebuild always beat
> the Portage ebuild even if the Portage build is newer (because it was
> updated without changing the version number), or will the newer ebuild
> always win out, whether it's in overlay or main Portage?

The overlay takes priority, even if the file date in the main portage tree
is newer. It's easy to test. copy a directory from the main tree to your
overlay, touch the latest ebuild in the main tree and emerge -pv the
package. You'll see that emerge picks the overlay version.

I noticed this when I wrote my own ebuild for a package and then someone
put it in portage. The first I new was when they released an r1 ebuild
and emerge --update world picked it up.

When you think about it, the very name "overlay" indicates that this is
how it should work.


-- 
Neil Bothwick

I have had a perfectly wonderful evening, but this wasn't it.

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

Re: [gentoo-user] modifying locally an ebuild

[Holly Bostick]

Neil Bothwick schreef:
> On Wed, 31 Aug 2005 14:42:16 +0200, Holly Bostick wrote:
> 
> 
>> But do you know the answer to Nick's question about what I said 
>> earlier? In a 'conflict' between two ebuilds of the same name and 
>> version, one in Portage and one in the overlay, does the choice of 
>> which one is used if I emerge the relevant package rely on which 
>> one is most recent(ly modified), or the location-- i.e., will the 
>> overlay ebuild always beat the Portage ebuild even if the Portage 
>> build is newer (because it was updated without changing the version
>>  number), or will the newer ebuild always win out, whether it's in 
>> overlay or main Portage?
> 
> 
> The overlay takes priority, even if the file date in the main portage
>  tree is newer.

OK, now that I'm thinking about it more (given that I'm actually awake
now), I do remember that I had to remove my overlay build of taskjuggler
in order to emerge the one that had been included in Portage. So I was
mistaken. It can happen, sorry ;) . Which is why, of course, I asked
you, Neil
(because you know, like, everything, just about :D ).

> It's easy to test. copy a directory from the main tree to your 
> overlay, touch the latest ebuild in the main tree and emerge -pv the
>  package. You'll see that emerge picks the overlay version.

You should know better than using the phrase 'it's easy' and the command
"'touch' whatever" in the same sentence when you're talking to me :) . I
kinda know how to 'touch', and I just learned how to 'grep' simple
strings (the operative word being 'simple'). It *is* easy, but honestly,
I'm well known to be the village idiot when it comes to the CLI, so your
easy test doesn't come naturally to me at all. :P

But it's good to be reminded of how such things can quickly be done.
Repeat it often enough, and it might even get caught in the sieve that
can be my brain.
> 
> I noticed this when I wrote my own ebuild for a package and then 
> someone put it in portage. The first I new was when they released an 
> r1 ebuild and emerge --update world picked it up.

Yes, I think that's what happened to me with taskjuggler as well.
> 
> When you think about it, the very name "overlay" indicates that this 
> is how it should work.

I suppose there's no way to avoid there being *some* issue-- this way,
you have to actively watch Portage to see if today is perhaps the happy
day that your overlay build is obsoleted; the other way, Portage would
be obsoleting your overlay build arbitrarily.

I don't see either of these as optimal conditions (since the goal, imo,
is to be using Portage builds and as few overlay builds as possible, and
neither of these conditions gives you a painless way to Return To
Portage, as it were), but I agree that the way it's currently done is
the better of two sub-optimal choices.

Holly
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] modifying locally an ebuild

[Neil Bothwick]

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

On Wed, 31 Aug 2005 16:06:17 +0200, Holly Bostick wrote:

> > When you think about it, the very name "overlay" indicates that this 
> > is how it should work.
> 
> I suppose there's no way to avoid there being *some* issue-- this way,
> you have to actively watch Portage to see if today is perhaps the happy
> day that your overlay build is obsoleted; the other way, Portage would
> be obsoleting your overlay build arbitrarily.

As long as your build is working the portage one wouldn't really obsolete
it. However, if you've altered an ebuild to suit your needs, you don't
want it replacing by the portage one just because the dev has corrected a
typo in a comment, altering the file's date.

> I don't see either of these as optimal conditions (since the goal, imo,
> is to be using Portage builds and as few overlay builds as possible, and
> neither of these conditions gives you a painless way to Return To
> Portage, as it were), but I agree that the way it's currently done is
> the better of two sub-optimal choices.

I suppose it would be possible to write a script that compares the ebuild
of everything you have installed from an overlay with the main portage
tree and warns you if there's been an update.



-- 
Neil Bothwick

Blessed be the pessimist for he hath made backups.

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

Re: [gentoo-user] modifying locally an ebuild

[Fernando Canizo]

El 31/ago/2005 a las 08:39 -0300, Holly me decía:
> The probelm here is (likely) that the name of the package (for the
> purposes of the ebuild) is 'mutt-conan', not mutt.
> 
> The format for an overlay folder (like Portage) is
> 
> cat-egory/package-name/package-name.and-version.ebuild
> 
> so your ebuild should likely be in
> 
> /usr/local/portage/mail-client/mutt-conan/mutt-conan-1.5.8-r2.ebuild
> 
> rather than just 'mutt'.
> 
> I get caught by that one all the time

And i get caught even after reading this. But now i read a second time
and get that the *directory* where the ebuild remains *must* have the
same name as the package. I didn't pay attentio to this:
> /usr/local/portage/ ... /mutt-conan/ ...

But before realizing that i just changed the name back to *mutt* alone
and the command run sucessfull. So i decided to let that way since
emerge will tell from where comes the ebuild, as you say.

I can't wait to see this tested, i'm doing a sync right now and gonna
unfix mutt version in packages.mask so this afternoon will check what
happens when i try to 'emerge mutt' (surely gonna be a new version)

> Is this a behaviour that a significant portion of the mutt userbase
> might want? Or are you just weird ;) ?

Well, you use thunderbird, so maybe you're more like a "mouse user".
This is the thing: in mutt you can flag a message as important (you
got only one flag), also you have a 'ctrl-d' command that deletes a
full thread. Sometimes threads get off-topic (an unconstructive flame
for example) and when i realize that, and don't like the new topic i
just 'ctrl-d' them. But what if i've flagged some message? It means
that it's important to me, so i wanted to remain undeleted.  The
actual behaviour of mutt just delete everything.

That's what the patch provides me, and with a single line of code.
Simple. And David (the autor) do it so well that even added a new
option for it to be in '~/muttrc' and let the default to be the old
behaviour. So i think this patch can get to portage easily.

By the way, if anyone interested, this is it:
http://home.uchicago.edu/~dgc/sw/mutt/patch-1.5.8.dgc.flagsafe.1

> If you think it might be useful to other mutt
> users, submit it to b.g.o 

Doing this later.

> :) Yes, you can. Isn't Gentoo great? Did you know yesterday that "even
> you" could contribute to development? $DEITY, I *love* that.... !

Yeah! I think it's time to read Nagatoro link now.

-- 
Fernando Canizo - http://www.lugmen.org.ar/~conan/
#if 0
        linux-2.2.16/fs/buffer.c
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] modifying locally an ebuild

[Holly Bostick]

Fernando Canizo schreef:

>> Is this a behaviour that a significant portion of the mutt userbase
>>  might want? Or are you just weird ;) ?
> 
> 
> Well, you use thunderbird, so maybe you're more like a "mouse user".

Yes, but I'm getting over it. Also I need to know how to work with at
least one CLI email client in the event that I don't have X available (I
have a fallback "no-X" alternative backend set up for most basic
functionality, exept email-- and heaven knows I never want to have to
try and read my ISP's webmail via lynx/elinks).

> This is the thing: in mutt you can flag a message as important (you 
> got only one flag), also you have a 'ctrl-d' command that deletes a 
> full thread. Sometimes threads get off-topic (an unconstructive flame
>  for example) and when i realize that, and don't like the new topic i
>  just 'ctrl-d' them. But what if i've flagged some message? It means 
> that it's important to me, so i wanted to remain undeleted.  The 
> actual behaviour of mutt just delete everything.
> 
> That's what the patch provides me, and with a single line of code. 
> Simple. And David (the autor) do it so well that even added a new 
> option for it to be in '~/muttrc' and let the default to be the old 
> behaviour. So i think this patch can get to portage easily.
> 
> By the way, if anyone interested, this is it: 
> http://home.uchicago.edu/~dgc/sw/mutt/patch-1.5.8.dgc.flagsafe.1

That really sounds incredibly useful. I can't imagine why upstream
wouldn't include that functionality. But obviously I know nothing about
Mutt, much less Mutt development goals.

> 
> 
>> If you think it might be useful to other mutt users, submit it to 
>> b.g.o
> 
> 
> Doing this later.

Glad to hear it. I'm sure I'll want it if I ever get around to using Mutt.

Holly
-- 
gentoo-user@gentoo.org mailing list

[gentoo-user] Re: modifying locally an ebuild

[Moshe Kaminsky]

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

> Fernando Canizo schreef:
> 
> > This is the thing: in mutt you can flag a message as important (you 
> > got only one flag), also you have a 'ctrl-d' command that deletes a 
> > full thread. Sometimes threads get off-topic (an unconstructive 
> > flame
> >  for example) and when i realize that, and don't like the new topic i
> >  just 'ctrl-d' them. But what if i've flagged some message? It means 
> > that it's important to me, so i wanted to remain undeleted.  The 
> > actual behaviour of mutt just delete everything.
> > 
> > That's what the patch provides me, and with a single line of code. 
> > Simple. And David (the autor) do it so well that even added a new 
> > option for it to be in '~/muttrc' and let the default to be the old 
> > behaviour. So i think this patch can get to portage easily.
> > 
> > By the way, if anyone interested, this is it: 
> > http://home.uchicago.edu/~dgc/sw/mutt/patch-1.5.8.dgc.flagsafe.1

This is a bit OT here (and I'm also replying to the wrong message, since 
I don't have the whole thread), but it seems that you can achieve the 
same goals without patching mutt: First, as you might be aware, it's 
possible to delete a subthread (bound by default to ESC d.) Second, I 
think you can do exactly what you want with something like:

macro index \Cd "\Ct .\n<esc>tD ~T ! ~F\n"
    "Delete unflagged thread messages"

(all in one line.) This untags all messages (\Ct .), tags the thread 
(<esc>t), then deletes messages which match the pattern that say the 
message is tagged (~T) and not flagged (! ~F). I assumed here that the 
key bindings are the default ones, and that you have 'delete_untag' set 
(otherwise you will want to untag them yourself, with an extra "\Ct ." 
at the end.) The only problem is that it will remove all tags you 
previously had.

Moshe


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