Re: [proaudio] (cvs|svn|git) vs 9999

[Dominique Michel <dominique.michel@xxxxxxxxxxxx>]

Le Fri, 11 Aug 2006 12:57:40 +0200,
Frieder Bürzele <evermind@xxxxxxxxxxxxx> a écrit :

> Dominique Michel wrote:
> > Le Fri, 11 Aug 2006 10:06:37 +0200,
> > Frieder Bürzele <evermind@xxxxxxxxxxxxx> a écrit :
> >
> >   
> >> carmen wrote:
> >>     
> >>> wondering if theres any concensus on -9999 versions vs seperate -cvs directories? with 9999, with -cvs, it breaks the continuity of one directory per package, and additional checks must be added to avoid conflicts.
> >>>
> >>> as an example, ive installed libgig-cvs. now on a -DNuav world, its trying to install libgig-2.0.2. i had to add libgig-9999 to package.provided (thus the seperate -cvs version didnt prevent me from /etc/portage file editing after all. id rather edit package.keywords once to enable -9999 version than have to continually do -uav to make sure non-cvs versions arent being brought in beacise i didnt populate package.provided.. preemptive handling of the situation.
> >>>
> >>> another example is the patchage-cvs and om-cvs ebuilds that i submitted a while ago. the author has changed to SVN, at a different host. at this point, the -cvs should be changed to -svn to be consistent (but still no consistency to whether a 'unreleased' version is -cvs, -svn, -git, -bzr, -mercurial, or what... confusing users as to which version to try). also it doesnt show up in eg eix or esearch 'available versions'. 
> >>>
> >>> in any case, my vote is for -9999. this is what the main portage tree does as well..
> >>>
> >>> c,c
> >>>
> >>>   
> >>>       
> >> first I just wanted to have -cvs -svn, -... in the overlay to see 
> >> clearly if it's a -cvs -svn, -...  snapshot or not.
> >> But over time I feel like using -9999 is the better way as it minimize 
> >> (I hope) maintenance.
> >>
> >> So If I change all -cvs -svn, -... to -9999 what keywords should they be?
> >> ~xARCH or -*
> >>
> >> @all
> >> please express your opinions? Should we change to 9999?
> >>
> >> Greetz
> >>     Frieder
> >>
> >>
> >>
> >>
> >>     
> > I don't care as long at it's work. But it is a good idea if it will
> > minimize the maintenance,
> >
> > For the keyboard, I don't know what will append if gentoo have a ~arch
> > version when we have the same program also with ~arch. It portage will
> > choose in all cases the -9999 in the overlay, I prefer ~arch, but if it
> > is not the case, -* will be better. So, can we have a certitude with
> > ~arch? I thing at the worst case will be if portage have a -9999 ~arch
> > ebuild at the same time as the overlay.
> >
> > Cheers,
> > Dominique
> >
> >   
> We can add -x86, (-arch whatever the package is capable),  instead of 
> ~x86 or -*
> So to add a -arch masked package:
> echo "category/packageName -arch" >> /etc/portage/package.keywords
> 
> maybe this is better than -*
> 
> Greetz
>     Frieder
> 
> 

On the gentoo dev manual,
http://devmanual.gentoo.org/keywording/index.html they write at -arch
mean at the package version will not work on the arch, when -* keyword
indicate package versions which are not worth trying to test on
unlisted archs.

If I look in sci-electronics/ng-spice-rework, it is a -9999 ebuild, and it use the -* keyword alone.
So, it will be best to use it if we want to be in accord with the way gentoo is developed. I know by experience at the cvs version of ngspice is very stable and will work in almost all cases.

I have the science overlay, and I just try to copy this ebuild in this overlay in order to have 2 identical ebuilds for this package. An "emerge -vp ng-spice-rework" showed me at portage will use the version from the overlay, not the one in gentoo. So it will be safe for us to use it.

It will also be less typing with -* as with -arch.

Cheers,
Dominique