[gentoo-dev] [RFC] C++ herd proposal

[gentoo-dev] [RFC] C++ herd proposal

[Mark Loeser]

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

Since we currently have language herds for other languages such as Ada,
Perl, and Java, I don't think C++ should be any different.  There are
currently many packages in the tree that are C++ libraries or utilities
that are no-herd and are actively maintained, and there are probably
some that have just been sitting around rotting.  With the creation of a
C++ herd, there would be a team that could support these packages,
instead of a single maintainer, if the package has one.  Below is a list
of all of the packages that I believe would qualify as falling under
this herd.  If you see your name in the following list, I'd especially
like to hear from you.  Names with a '?' next to them are packages that
had no metadata and I guessed from the changelog who the maintainer is.
 I would also like to see many of them, if not all, moved to the dev-cpp
category:

dev-cpp/commoncpp2          (no-herd, arj)
dev-cpp/gccxml              (no-herd, g2boojum)
dev-cpp/libibinio           (no-herd, spock)
dev-cpp/poslib              (no-herd, matsuu)
dev-cpp/rudiments           (no-herd, matsuu)
dev-db/libodbc++            (no-herd, robbat2)
dev-libs/STLport            (no-herd, vapier?)
dev-libs/asyncresolv        (no-herd, jhhudso?)
dev-libs/blitz              (no-herd, dragonheart)
dev-libs/boost              (no-herd, morfic)
dev-libs/cgicc              (no-herd, ka0ttic)
dev-libs/commonc++          (duplicate of dev-cpp/commoncpp2 as far as I
can tell, unmaintained?)
dev-libs/darts              (no-herd, unmaintained?)
dev-libs/dvacm4             (no-herd, pvdabeel?)
dev-libs/dvcgi              (no-herd, ka0ttic)
dev-libs/dvutil             (no-herd, ka0ttic)
dev-libs/fampp2             (no-herd, vapier)
dev-libs/ferrisloki         (no-herd, vapier)
dev-libs/ibpp               (no-herd, sekretarz)
dev-libs/korelib            (no-herd, george?)
dev-libs/libcoyotl          (no-herd, aliz)
dev-libs/libevocosm         (no-herd, aliz)
dev-libs/libferrisstreams   (no-herd, vapier)
dev-libs/log4cpp            (no-herd, george?)
dev-libs/log4cxx            (no-herd, ka0ttic)
dev-libs/luabind            (no-herd, rphillips)
dev-libs/ntl                (no-herd, george?)
dev-libs/pcre++             (no-herd, eradicator)
dev-libs/ptypes             (no-herd, dragonheart? george?)
dev-libs/quantlib           (no-herd, vanquirius)
dev-libs/rlog               (no-herd, vanquirius)
dev-libs/socketstream       (no-herd, george? dragonheart?)
dev-libs/sucs               (no-herd, ka0ttic)
dev-libs/swl                (no-herd, trapni upstream dead? The site
appears to be dead)
dev-libs/wefts              (no-herd, flameeyes)
dev-libs/xerces-c           (no-herd, halcy0n)
dev-libs/xmlwrapp           (no-herd, ka0ttic)
dev-libs/yaz++              (no-herd, robbat2)
dev-util/leaktracer         (no-herd, svyatogor?)
net-libs/socket++           (no-herd, ka0ttic)

Possible candidates (most of these are for C and C++):
dev-libs/nana               (no-herd, pyrania?)
dev-libs/xmlrpc-c           (no-herd, jhhudso)
dev-libs/xxl                (no-herd, ka0ttic)
dev-util/astyle             (no-herd, karltk)
dev-util/bcpp               (no-herd, chriswhite?)
dev-util/cccc               (no-herd, dragonheart?)
dev-util/ccmalloc           (no-herd, dholm)
dev-util/cdecl              (no-herd, phosphan)
dev-util/cweb               (no-herd, no one)
dev-util/flawfinder         (no-herd, aliz?)
dev-util/rats               (no-herd, robbat2)

Currently under another herd, but seems to make more sense here:

dev-cpp/libxmlpp            (gnome-mm, ka0ttic)
dev-cpp/sptk                (desktop-misc, iluxa?)
dev-libs/libsigc++          (gnome-mm, ka0ttic)
dev-libs/libsigcx           (gnome-mm, ka0ttic)
dev-libs/mxmlplus           (text-markup, usata)
dev-libs/xplc               (net-dialup, mrness)
dev-util/cppunit            (lang-misc, george?)
dev-util/qtunit             (kde, centic?)
net-libs/wvstreams          (net-dialup, mrness?)


I would like all of the current maintainers of these packages to keep
maintaining them, and they wouldn't be required to join the cpp team,
but there are a few people that seem to maintain quite a few C++
libraries that might be interested in joining.

If there is not a very good reason against the creation of this herd, I
would like to do so in the coming week.  As for the name, cpp may be a
little misleading, any better suggestions?  In the list above, I have
libraries for C++, as well as utilities.

Thanks,

Mark

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

Re: [gentoo-dev] [RFC] C++ herd proposal

[Mike Frysinger]

On Friday 16 September 2005 06:20 pm, Mark Loeser wrote:
> Since we currently have language herds for other languages such as Ada,
> Perl, and Java, I don't think C++ should be any different.

it is different, but i dont mind the idea of having a bunch of C++ experts 
looking over a bunch of packages which otherwise may be neglected

> dev-libs/STLport            (no-herd, vapier?)

vapier/toolchain

> dev-libs/fampp2             (no-herd, vapier)
> dev-libs/ferrisloki         (no-herd, vapier)
> dev-libs/libferrisstreams   (no-herd, vapier)
> dev-db/stldb4

generally i dont need help with these as the upstream author is a pretty cool 
guy and gets back to me :)
-mike
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [RFC] C++ herd proposal

[Christian Parpart]

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

On Saturday 17 September 2005 01:20, Mike Frysinger wrote:
> On Friday 16 September 2005 06:20 pm, Mark Loeser wrote:
> > Since we currently have language herds for other languages such as Ada,
> > Perl, and Java, I don't think C++ should be any different.
>
> it is different, but i dont mind the idea of having a bunch of C++ experts
> looking over a bunch of packages which otherwise may be neglected

And that's the point I see in as well - having some central point for our C++ 
experts/freaks. Of course, a c++ herd would not just be like ADA/Java IMO.

Though, I vote FOR such a herd (and would like to join anyway)

> > dev-libs/STLport            (no-herd, vapier?)
>
> vapier/toolchain
>
> > dev-libs/fampp2             (no-herd, vapier)
> > dev-libs/ferrisloki         (no-herd, vapier)
> > dev-libs/libferrisstreams   (no-herd, vapier)
> > dev-db/stldb4
>
> generally i dont need help with these as the upstream author is a pretty
> cool guy and gets back to me :)
> -mike

but having some backup is always the safer way, in case some of us is AFK for 
some unobvious reasons and a security patch is to be injected.

Regards,
Christian Parpart

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

Re: [gentoo-dev] [RFC] C++ herd proposal

[Aaron Walker]

Mark Loeser wrote:
> Since we currently have language herds for other languages such as Ada,
> Perl, and Java, I don't think C++ should be any different.  There are
> currently many packages in the tree that are C++ libraries or utilities
> that are no-herd and are actively maintained, and there are probably
> some that have just been sitting around rotting.  With the creation of a
> C++ herd, there would be a team that could support these packages,
> instead of a single maintainer, if the package has one.  Below is a list
> of all of the packages that I believe would qualify as falling under
> this herd.  If you see your name in the following list, I'd especially
> like to hear from you.  Names with a '?' next to them are packages that
> had no metadata and I guessed from the changelog who the maintainer is.
>  I would also like to see many of them, if not all, moved to the dev-cpp
> category:
> 
<snip>

I'm game.

-- 
Who's scruffy-looking?
		-- Han Solo

Aaron Walker <ka0ttic@gentoo.org>
[ BSD | commonbox | cron | cvs-utils | mips | netmon | shell-tools | vim ]
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [RFC] C++ herd proposal

[Ciaran McCreesh]

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

On Fri, 16 Sep 2005 18:20:57 -0400 Mark Loeser <halcy0n@gentoo.org>
wrote:
| Since we currently have language herds for other languages such as
| Ada, Perl, and Java, I don't think C++ should be any different.
| There are currently many packages in the tree that are C++ libraries
| or utilities that are no-herd and are actively maintained, and there
| are probably some that have just been sitting around rotting.  With
| the creation of a C++ herd, there would be a team that could support
| these packages, instead of a single maintainer, if the package has
| one.  Below is a list of all of the packages that I believe would
| qualify as falling under this herd.  If you see your name in the
| following list, I'd especially like to hear from you.  Names with a
| '?' next to them are packages that had no metadata and I guessed from
| the changelog who the maintainer is. I would also like to see many of
| them, if not all, moved to the dev-cpp
| category:

I use some of those. Count me in, so long as I don't ever have to touch
the hideous monstrosity that is boost...

-- 
Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


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

Re: [gentoo-dev] [RFC] C++ herd proposal

[Robin H. Johnson]

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

On Fri, Sep 16, 2005 at 06:20:57PM -0400, Mark Loeser wrote:
> dev-util/flawfinder         (no-herd, aliz?)
> dev-util/rats               (no-herd, robbat2)
I'm a large user of these, but for rats there really isn't any
maintaining to do, upstream hasn't changed the code in 18+ months, and
it works fine still.

-- 
Robin Hugh Johnson
E-Mail     : robbat2@orbis-terrarum.net
Home Page  : http://www.orbis-terrarum.net/?l=people.robbat2
ICQ#       : 30269588 or 41961639
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85

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

Re: [gentoo-dev] [RFC] C++ herd proposal

[Kevin F. Quinn]

On 17/9/2005 0:20:57, Mark Loeser (halcy0n@gentoo.org) wrote:

C++ herd is a good idea, especially with that number of packages.

>  I would also like to see many of them, if not all, moved to the dev-cpp
> category:

Is this bit really necessary?


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [RFC] C++ herd proposal

[Christian Parpart]

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

On Saturday 17 September 2005 11:36, Kevin F. Quinn wrote:
> On 17/9/2005 0:20:57, Mark Loeser (halcy0n@gentoo.org) wrote:
>
> C++ herd is a good idea, especially with that number of packages.
>
> >  I would also like to see many of them, if not all, moved to the dev-cpp
> > category:
>
> Is this bit really necessary?

indeed, it at least helps curious c++ devs to browse through some yet unknown 
c++ libs and he maybe finds something useful.

Regards,
Christian Parpart.

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

Re: [gentoo-dev] [RFC] C++ herd proposal

[Kevin F. Quinn]

On 17/9/2005 13:33:30, Christian Parpart (trapni@gentoo.org) wrote:
> On Saturday 17 September 2005 11:36, Kevin F. Quinn wrote:
> > On 17/9/2005 0:20:57, Mark Loeser (halcy0n@gentoo.org) wrote:
> >
> > C++ herd is a good idea, especially with that number of packages.
> >
> > >  I would also like to see many of them, if not all, moved to the 
> > > dev-cpp category:
> >
> > Is this bit really necessary?
> 
> indeed, it at least helps curious c++ devs to browse through some yet 
> unknown c++ libs and he maybe finds something useful.

If the only gain is that one group finds one search criteria a little easier,
then I think that is far from sufficient reason to re-categorise.

What about people searching in the application domain (which to be honest
I think is much more likely)?  Under your approach they have to rummage
around in each dev-<lang> category, hoping that it'll be obvious from the
package name that it's suitable for their application domain.

What happens when the media, games or net herds come along, and want to
pull stuff into a media-libs, dev-games, net-libs?  We end up in a
tug-of-war between competing interests.

Think also of all the work involved in re-categorising stuff; how everyone
with dependencies on these packages in their overlay will have to rework
stuff in their overlay, all because of one group's nice-to-have.  It's
particularly acute for libraries.

I think we should discourage the idea that filesystem categories and herds
are related at all, and think of filesystem categories simply as convenient
buckets preventing lists of packages getting long.  Resist the urge to
re-categorise as much as possible, because in the end it's pointless.

Instead, add to metadata, and use that to find stuff.  In metadata.xml,
we could have as many search criteria as we like; for example source
language(s), library|application, application domain (sound, games, video)
which can happily cope with many->many relationships.

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [RFC] C++ herd proposal

[Christian Parpart]

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

On Saturday 17 September 2005 14:01, Kevin F. Quinn wrote:
> On 17/9/2005 13:33:30, Christian Parpart (trapni@gentoo.org) wrote:
> > On Saturday 17 September 2005 11:36, Kevin F. Quinn wrote:
> > > On 17/9/2005 0:20:57, Mark Loeser (halcy0n@gentoo.org) wrote:
> > >
> > > C++ herd is a good idea, especially with that number of packages.
> > >
> > > >  I would also like to see many of them, if not all, moved to the
> > > > dev-cpp category:
> > >
> > > Is this bit really necessary?
> >
> > indeed, it at least helps curious c++ devs to browse through some yet
> > unknown c++ libs and he maybe finds something useful.
>
> If the only gain is that one group finds one search criteria a little
> easier, then I think that is far from sufficient reason to re-categorise.

errr... I didn't meant "of course" == "indeed", I meant it a way of "that 
might make sense". sorry for the misunderstandings ;)

Regards,
Christian.

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

Re: [gentoo-dev] [RFC] C++ herd proposal

[Mark Loeser]

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

Kevin F. Quinn wrote:
>> I would also like to see many of them, if not all, moved to the dev-cpp
>>category:
> 
> 
> Is this bit really necessary?

The reason for me adding that bit is the metadata from dev-cpp:

The dev-cpp category contains libraries and utilities relevant to the
c++ programming language.

Now to me, that means I can find *all* relevant C++ stuff here.  If we
don't want that to be the case, maybe we should say "miscellaneous", but
why should something be in dev-libs, as compared with dev-cpp?
net-libs, I could understand, and dev-games, as those could be argued to
have a direct relation.  This is really just a matter of categorization,
and isn't as big of a concern for me as it is trying to put all of these
no-herd packages under a herd.

Mark

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

Re: [gentoo-dev] [RFC] C++ herd proposal

[Mike Frysinger]

On Saturday 17 September 2005 02:22 pm, Mark Loeser wrote:
> Kevin F. Quinn wrote:
> >> I would also like to see many of them, if not all, moved to the dev-cpp
> >>category:
> >
> > Is this bit really necessary?
>
> The reason for me adding that bit is the metadata from dev-cpp:
>
> The dev-cpp category contains libraries and utilities relevant to the
> c++ programming language.
>
> Now to me, that means I can find *all* relevant C++ stuff here.  If we
> don't want that to be the case, maybe we should say "miscellaneous", but
> why should something be in dev-libs, as compared with dev-cpp?
> net-libs, I could understand, and dev-games, as those could be argued to
> have a direct relation.

for generic C++ packages (STLport/boost for example), i can see them being in 
the dev-cpp category ... but for packages which have specific uses already 
and arent in 'generic' categories, i dont think they should be moved
-mike
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [RFC] C++ herd proposal

[Mark Loeser]

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

Mike Frysinger wrote:
> On Saturday 17 September 2005 02:22 pm, Mark Loeser wrote:
>>The reason for me adding that bit is the metadata from dev-cpp:
>>
>>The dev-cpp category contains libraries and utilities relevant to the
>>c++ programming language.
>>
>>Now to me, that means I can find *all* relevant C++ stuff here.  If we
>>don't want that to be the case, maybe we should say "miscellaneous", but
>>why should something be in dev-libs, as compared with dev-cpp?
>>net-libs, I could understand, and dev-games, as those could be argued to
>>have a direct relation.
> 
> 
> for generic C++ packages (STLport/boost for example), i can see them being in 
> the dev-cpp category ... but for packages which have specific uses already 
> and arent in 'generic' categories, i dont think they should be moved

I agree with this, but I think dev-libs and dev-util are generic
categories, and moving these packages from there would help users in
finding what they need.  I think this is what you are saying atleast :)

Mark

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

Re: [gentoo-dev] [RFC] C++ herd proposal

[Paul de Vrieze]

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

On Saturday 17 September 2005 22:24, Mark Loeser wrote:
> Mike Frysinger wrote:
> > On Saturday 17 September 2005 02:22 pm, Mark Loeser wrote:
> >>The reason for me adding that bit is the metadata from dev-cpp:
> >>
> >>The dev-cpp category contains libraries and utilities relevant to the
> >>c++ programming language.
> >>
> >>Now to me, that means I can find *all* relevant C++ stuff here.  If
> >> we don't want that to be the case, maybe we should say
> >> "miscellaneous", but why should something be in dev-libs, as
> >> compared with dev-cpp? net-libs, I could understand, and dev-games,
> >> as those could be argued to have a direct relation.
> >
> > for generic C++ packages (STLport/boost for example), i can see them
> > being in the dev-cpp category ... but for packages which have
> > specific uses already and arent in 'generic' categories, i dont think
> > they should be moved
>
> I agree with this, but I think dev-libs and dev-util are generic
> categories, and moving these packages from there would help users in
> finding what they need.  I think this is what you are saying atleast :)

I think that dev-util is a very specific category containing development 
utilities of some sort. There might be some misclassifications in them, 
but from a user perspective I don't really care about the language 
anything is written in. As C++ is so widespread I don't think that 
anything but app-misc or the like should be moved into a dev-cpp 
category.

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] [RFC] C++ herd proposal

[Mark Loeser]

Paul de Vrieze wrote:
> I think that dev-util is a very specific category containing development 
> utilities of some sort. There might be some misclassifications in them, 
> but from a user perspective I don't really care about the language 
> anything is written in. As C++ is so widespread I don't think that 
> anything but app-misc or the like should be moved into a dev-cpp 
> category.


This isn't for what the package is written in, but more for what the 
package is for.  If the package is a utility for use when doing coding 
with C++, like the ones I listed, then I think it should be in dev-cpp. 
  That's what the metadata for the category describes it to be.

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

Re: [gentoo-dev] [RFC] C++ herd proposal

[warnera6]

Mark Loeser wrote:
> Paul de Vrieze wrote:
> 
>> I think that dev-util is a very specific category containing 
>> development utilities of some sort. There might be some 
>> misclassifications in them, but from a user perspective I don't really 
>> care about the language anything is written in. As C++ is so 
>> widespread I don't think that anything but app-misc or the like should 
>> be moved into a dev-cpp category.
> 
> 
> 
> This isn't for what the package is written in, but more for what the 
> package is for.  If the package is a utility for use when doing coding 
> with C++, like the ones I listed, then I think it should be in dev-cpp. 
>  That's what the metadata for the category describes it to be.
> 
> Mark

Once again I'd like to point out that organizing packages in the tree by 
category is a stupid idea for this very reason.
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [RFC] C++ herd proposal

[Christian Parpart]

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

On Monday 19 September 2005 15:22, warnera6 wrote:
> Mark Loeser wrote:
> > Paul de Vrieze wrote:
> >> I think that dev-util is a very specific category containing
> >> development utilities of some sort. There might be some
> >> misclassifications in them, but from a user perspective I don't really
> >> care about the language anything is written in. As C++ is so
> >> widespread I don't think that anything but app-misc or the like should
> >> be moved into a dev-cpp category.
> >
> > This isn't for what the package is written in, but more for what the
> > package is for.  If the package is a utility for use when doing coding
> > with C++, like the ones I listed, then I think it should be in dev-cpp.
> >  That's what the metadata for the category describes it to be.
> >
> > Mark
>
> Once again I'd like to point out that organizing packages in the tree by
> category is a stupid idea for this very reason.

and what's *your* certain proposal then?

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

Re: [gentoo-dev] [RFC] C++ herd proposal

[Georgi Georgiev]

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

maillog: 20/09/2005-07:21:08(+0200): Christian Parpart types
> On Monday 19 September 2005 15:22, warnera6 wrote:
> > Mark Loeser wrote:
> > > Paul de Vrieze wrote:
> > >> I think that dev-util is a very specific category containing
> > >> development utilities of some sort. There might be some
> > >> misclassifications in them, but from a user perspective I don't really
> > >> care about the language anything is written in. As C++ is so
> > >> widespread I don't think that anything but app-misc or the like should
> > >> be moved into a dev-cpp category.
> > >
> > > This isn't for what the package is written in, but more for what the
> > > package is for.  If the package is a utility for use when doing coding
> > > with C++, like the ones I listed, then I think it should be in dev-cpp.
> > >  That's what the metadata for the category describes it to be.
> > >
> > > Mark
> >
> > Once again I'd like to point out that organizing packages in the tree by
> > category is a stupid idea for this very reason.
> 
> and what's *your* certain proposal then?

That's been discussed a number of times already. The best idea is to
leave the categories alone and forget that the category means anything.
Or, to throw the ball back in your court, could *you* suggest
alternatives that accomplish the following:

(quoting [1]:)

More precisely, what I'd like to see, in order of preference, is

- that package in my overlay that has net-wireless/gnome-phone-manager
  in its *DEPENDs to work for as long as needed
- the net-wireless/gnome-phone-manager that I have in my overlay to work
  for as long as needed
- my net-wireless/gnome-phone-manager binary packages to work without
  having to be "fixpackage"d
- the location of the ebuilds for net-wireless/gnome-phone-manager to
  stay in the same physical path on my filesystem 

end quote

I would grade the above features as "vital", "badly needed", "happy to
see it done", "cosmetic". I.e., even solving only the first one is
enough, though if you could get to number two it would be better.

1:
http://groups.google.com/group/linux.gentoo.dev/tree/browse_frm/thread/26b3b93fe16de00c/3ffe93800adbc578?fwc=1#o3ffe93800adbc578

-- 
/\   Georgi Georgiev   /\ Vulcans never bluff. -- Spock, "The Doomsday /\
\/    chutz@gg3.net    \/ Machine", stardate 4202.1                    \/
/\  +81(90)2877-8845   /\                                              /\

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

Re: [gentoo-dev] [RFC] C++ herd proposal

[Alin Nastac]

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

Georgi Georgiev wrote:

>- that package in my overlay that has net-wireless/gnome-phone-manager
>  in its *DEPENDs to work for as long as needed
>  
>
gnome-phone-manager can be found in portage tree under app-mobilephone
category.

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

Re: [gentoo-dev] [RFC] C++ herd proposal

[Georgi Georgiev]

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

maillog: 20/09/2005-09:37:23(+0300): Alin Nastac types
> Georgi Georgiev wrote:
> 
> >- that package in my overlay that has net-wireless/gnome-phone-manager
> >  in its *DEPENDs to work for as long as needed
> >  
> >
> gnome-phone-manager can be found in portage tree under app-mobilephone
> category.

So that's why my overlay got screwed up!

But seriously, this only supports my point -- category moves are evil.

-- 
 /   Georgi Georgiev    / Putt's Law: Technology is dominated by two    /
\     chutz@gg3.net    \  types of people: Those who understand what   \
 /  +81(90)2877-8845    / they do not manage. Those who manage what     /
\  ------------------- \  they do not understand.                      \

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

Re: [gentoo-dev] [RFC] C++ herd proposal

[Alin Nastac]

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

Georgi Georgiev wrote:

>maillog: 20/09/2005-09:37:23(+0300): Alin Nastac types
>  
>
>>Georgi Georgiev wrote:
>>
>>    
>>
>>>- that package in my overlay that has net-wireless/gnome-phone-manager
>>> in its *DEPENDs to work for as long as needed
>>> 
>>>
>>>      
>>>
>>gnome-phone-manager can be found in portage tree under app-mobilephone
>>category.
>>    
>>
>
>So that's why my overlay got screwed up!
>
>But seriously, this only supports my point -- category moves are evil.
>
>  
>
portage isn't supposed to offer eternal functionality status for
personal overlays. what if an eclass gets obsoleted and eventually is
removed from the tree?
the only problem is binary packages screw up.


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

Re: [gentoo-dev] [RFC] C++ herd proposal

[Brian Harring]

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

On Tue, Sep 20, 2005 at 10:01:39AM +0300, Alin Nastac wrote:
> Georgi Georgiev wrote:
> >maillog: 20/09/2005-09:37:23(+0300): Alin Nastac types
> >>Georgi Georgiev wrote:
> >>>- that package in my overlay that has net-wireless/gnome-phone-manager
> >>> in its *DEPENDs to work for as long as needed
> >>>
> >>gnome-phone-manager can be found in portage tree under app-mobilephone
> >>category.
> >
> >So that's why my overlay got screwed up!
> >
> >But seriously, this only supports my point -- category moves are evil.

> portage isn't supposed to offer eternal functionality status for
> personal overlays.
Eh?

> what if an eclass gets obsoleted and eventually is
> removed from the tree?
Pull from viewcvs.  I assume you're talking about portage >=2.1 
capabilities, since you *cannot* remove an eclass from the tree once 
it's been added currently.

> the only problem is binary packages screw up.
Binpkgs should be running from their own env, they should be stand 
alone not requiring even a tree.

Back on subject... I *really* don't like categories.  Single vdb, 
single repo, single binpkg, it's not horrible.  Multiple true, 
standalone repos, with the occasional binpkg repo used?  It makes 
doing the category move *really* rather hard, since you need to track 
down exactly which repository and ebuild came from.
~harring

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

Re: [gentoo-dev] [RFC] C++ herd proposal

[Kevin F. Quinn]

On 20/9/2005 7:37:19, Georgi Georgiev (chutz@gg3.net) wrote:
> maillog: 20/09/2005-07:21:08(+0200): Christian Parpart types
> > On Monday 19 September 2005 15:22, warnera6 wrote:
> > > Mark Loeser wrote:
> > > > Paul de Vrieze wrote:
> > > >> I think that dev-util is a very specific category containing
> > > >> development utilities of some sort. There might be some
> > > >> misclassifications in them, but from a user perspective I don't 
> > > >> really care about the language anything is written in. As C++ is so
> > > >> widespread I don't think that anything but app-misc or the like 
> > > >> should be moved into a dev-cpp category.
> > > >
> > > > This isn't for what the package is written in, but more for what the
> > > > package is for.  If the package is a utility for use when doing 
> > > > coding with C++, like the ones I listed, then I think it should be 
> > > >  in dev-cpp. That's what the metadata for the category describes it 
> > > >to be. 
> > > > Mark
> > >
> > > Once again I'd like to point out that organizing packages in the tree 
> > > by category is a stupid idea for this very reason.
> > 
> > and what's *your* certain proposal then?
> 
> That's been discussed a number of times already. The best idea is to
> leave the categories alone and forget that the category means anything.
> Or, to throw the ball back in your court, could *you* suggest
> alternatives that accomplish the following:
> 
> (quoting [1]:)
> 
> More precisely, what I'd like to see, in order of preference, is
> 
> - that package in my overlay that has net-wireless/gnome-phone-manager
>   in its *DEPENDs to work for as long as needed
> - the net-wireless/gnome-phone-manager that I have in my overlay to work
>   for as long as needed
> - my net-wireless/gnome-phone-manager binary packages to work without
>   having to be "fixpackage"d
> - the location of the ebuilds for net-wireless/gnome-phone-manager to
>   stay in the same physical path on my filesystem 
> 
> end quote
> I would grade the above features as "vital", "badly needed", "happy to
> see it done", "cosmetic". I.e., even solving only the first one is
> enough, though if you could get to number two it would be better.


Here's another requirement I'd like to add to the list:

- when moving stuff around, change history moves too

CVS doesn't support this, but subversion does (along with atomic commits,
also useful to ensure integrity of the tree during a move).  The support
for symlinks in subversion may also provide a way to resolve the overlay
problem...

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [RFC] C++ herd proposal

[Martin Schlemmer]

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

On Tue, 2005-09-20 at 08:54 +0200, Kevin F. Quinn wrote:
> On 20/9/2005 7:37:19, Georgi Georgiev (chutz@gg3.net) wrote:
> > maillog: 20/09/2005-07:21:08(+0200): Christian Parpart types
> > > On Monday 19 September 2005 15:22, warnera6 wrote:
> > > > Mark Loeser wrote:
> > > > > Paul de Vrieze wrote:
> > > > >> I think that dev-util is a very specific category containing
> > > > >> development utilities of some sort. There might be some
> > > > >> misclassifications in them, but from a user perspective I don't 
> > > > >> really care about the language anything is written in. As C++ is so
> > > > >> widespread I don't think that anything but app-misc or the like 
> > > > >> should be moved into a dev-cpp category.
> > > > >
> > > > > This isn't for what the package is written in, but more for what the
> > > > > package is for.  If the package is a utility for use when doing 
> > > > > coding with C++, like the ones I listed, then I think it should be 
> > > > >  in dev-cpp. That's what the metadata for the category describes it 
> > > > >to be. 
> > > > > Mark
> > > >
> > > > Once again I'd like to point out that organizing packages in the tree 
> > > > by category is a stupid idea for this very reason.
> > > 
> > > and what's *your* certain proposal then?
> > 
> > That's been discussed a number of times already. The best idea is to
> > leave the categories alone and forget that the category means anything.
> > Or, to throw the ball back in your court, could *you* suggest
> > alternatives that accomplish the following:
> > 
> > (quoting [1]:)
> > 
> > More precisely, what I'd like to see, in order of preference, is
> > 
> > - that package in my overlay that has net-wireless/gnome-phone-manager
> >   in its *DEPENDs to work for as long as needed
> > - the net-wireless/gnome-phone-manager that I have in my overlay to work
> >   for as long as needed
> > - my net-wireless/gnome-phone-manager binary packages to work without
> >   having to be "fixpackage"d
> > - the location of the ebuilds for net-wireless/gnome-phone-manager to
> >   stay in the same physical path on my filesystem 
> > 
> > end quote
> > I would grade the above features as "vital", "badly needed", "happy to
> > see it done", "cosmetic". I.e., even solving only the first one is
> > enough, though if you could get to number two it would be better.
> 
> 
> Here's another requirement I'd like to add to the list:
> 
> - when moving stuff around, change history moves too
> 
> CVS doesn't support this, but subversion does (along with atomic commits,
> also useful to ensure integrity of the tree during a move).  The support
> for symlinks in subversion may also provide a way to resolve the overlay
> problem...
> 

Technically it does support it if said developer gets Infra to move it
server side ....  some nasty side effects, etc, but lots better than our
current situation where some bright spark removed most if not all
history of stuff that was moved :/


-- 
Martin Schlemmer


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] [RFC] C++ herd proposal

[Donnie Berkholz]

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

Martin Schlemmer wrote:
| Technically it does support it if said developer gets Infra to move it
| server side ....  some nasty side effects, etc, but lots better than our
| current situation where some bright spark removed most if not all
| history of stuff that was moved :/

Not really any side effects if you do it right. Copy the ,v files (don't
just mv them), then cvs rm in the old location.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFDMDmaXVaO67S1rtsRApZtAKCefgS2okfjNcpQpBUekthLdj4XhgCguCMQ
zFLmx9mPBX+dYwR/YS5WE6M=
=BwBQ
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [RFC] C++ herd proposal

[Christian Parpart]

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

On Saturday 17 September 2005 22:14, Mike Frysinger wrote:
> On Saturday 17 September 2005 02:22 pm, Mark Loeser wrote:
> > Kevin F. Quinn wrote:
> > >> I would also like to see many of them, if not all, moved to the
> > >> dev-cpp category:
> > >
> > > Is this bit really necessary?
> >
> > The reason for me adding that bit is the metadata from dev-cpp:
> >
> > The dev-cpp category contains libraries and utilities relevant to the
> > c++ programming language.
> >
> > Now to me, that means I can find *all* relevant C++ stuff here.  If we
> > don't want that to be the case, maybe we should say "miscellaneous", but
> > why should something be in dev-libs, as compared with dev-cpp?
> > net-libs, I could understand, and dev-games, as those could be argued to
> > have a direct relation.
>
> for generic C++ packages (STLport/boost for example), i can see them being
> in the dev-cpp category ... but for packages which have specific uses
> already and arent in 'generic' categories, i dont think they should be
> moved -mike

if I do understand you correctly, I'd even not use dev-cpp as category, 
instead something that contains the word `platform` or `framework` in it, as 
STLport/boost/STL(libstdc++-v3,...) and others are exactly of that kind.

However, we've some more no-herd'ed packages to put into this new potential 
c++ herd - but these are two different discussions/threads IMHO.

Regards,
Christian Parpart.

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