As discussed on the gentoo-science mailing list, there is an interest for splitting "app-sci" (180+ packages) in smaller, more specific categories.
Created attachment 43553 [details] sci-split.txt - List of "app-sci" applications split in smaller categories This is an updated version of Fonseca's list (posted on the mailing list). I can confirm that the planned "sci-biology" category contains all biology related applications, and only biology related applications. I am also pretty sure this is the case for "sci-chemistry" as well. Other categories, especially "sci-electronics" and "sci-math" should be revised to ensure they are OK too. To minimize the overlap between chemistry and biology related applications, I put everything related to molecular modeling in chemistry. I left all the proposed smaller categories intact, but when a final decision is made, they will probably be integrated in "sci-misc" anyway. Also, many packages should be moved from their actual categories to "sci-libs". I did not include any package from "dev-libs" or other categories. I think we should first decide how to split the packages in "app-sci".
Hi Olivier Thanks for opening this bug. Based on the amount of interest I really see now that this split is even overdue :). Few small things for now: 1. sci-cad and sci-geography are kind of small. How many more packages are "planned" for them? May be these packages should stay in -misc for a while? We'll just "reserve" these categories now :). 2. Is this really all for sci-libs? In such case it might be worth trying to move them elsewhenre, like many other libs (e.g. blas/lapack) . For example cdf can go into -math and -libnova into astronomy. 3. More of a remark. There are 98 new submissions on bugzilla, but they clearly will have to wait for this reorg and, hopefully, more maintainers :). George
Hi George, 1. Yes, that is what I meant by "smaller categories": cad, geography and simulation are way too small to justify a category (right now). Even astronomy and calculator are bordeline. (I personally think we should implement these two categories, but I would like to have others' opinions.) 2. Lots of things could be moved to "sci-libs", such as acml, blas*, lapack*, libgdgeda, libgeda, udunits, netcfd, primegen. I was hoping someone more familiar with math software could do it. ;-) And maybe someone more familiar with math could also split the math stuff using the appropriate categories (stat, simu, hpc, linalg, or whatever makes sense)?
This is a newbie question, so sorry if it is answered elsewhere, but is there a problem with starting categories off small and letting them grow? CAD in particular - right now linux is really weak on CAD, but one would hope this state of affairs is not perminant. About sci-lib - I agree this makes a lot of sense, but what do we do about libs that are specific to a category? (e.g., if we were to have a CAD category, where would Open CASCADE go, for example?)
The effort to create a new category is pretty low, so there's no point in creating more than necessary at a given point in time. Also, you can't assume it's going to grow, even if you're hoping it will.
I wasn't thinking as much of future growth as I was of making it easy to tell that there are kinds of apps gentoo doesn't have, as well as what it does have. If someone wants a robust 3D CAD app, they might spend quite a while digging through sci-misc before coming to the realization that their choices are quite limited. But, I do concede the point that there must be practical limits, and in that light it does make more sense to put things in sci-misc for now and avoid opening cans of worms.
Created attachment 45872 [details] sci-split.txt - Updated listing Here is an updated list of "app-sci" packages split into smaller categories. I moved the appropriate packages from "app-sci" and "dev-libs" to "sci-libs". I would appreciate if someone familiar with mathematics packages could check over the list. I will announce the split to "gentoo-dev" at the end of this week (unless developers from the sci herd want more time to review the list).
a few nits: 1. I would put beagle with gaul; both are "evolutionary computing" libraries 2. The mars rover and lightspeed packages probably belong in astronomy 3. Do you want to move R from "dev-lang" to math? It's both a language and a mathematical environment. Debian has it in math, for what it's worth. 4. I'd put tilp with the calculators. 5. Should "chessbrain" be in a "games" category? 6. gempak and vis5d belong together, I think
More comments from nerdboy/mr_science: Vis5D is for arbitrary data (often used for metetorology and earth science), whereas gempak is pretty much exclusively for meteorology data display. sc-libs should probably add hdf(4), hdf5, netcdf, udunits, and the others already mentioned (some are in the new list already). My final nit: please move [geography packages in sci-misc] back to it's own category, perhaps sci-geo. I have many packages to add, mostly GIS, mapping, and earth science related packages. Here are a few: grass proj shapelib gdal gempak gmt ogr mapserver zmapserver pcl zco anything to do with gps gstat ldm openev vtp Some of the above I'm still creating ebuilds for, also several have depends on various graphics libs, mapping/GIS libs, and other earth science stuff. The list will continue to grow as I add new packages and find others in the portage tree... Finally, it still makes sense to maintain some sci-herd umbrella over these smaller categories (I guess I've been too busy to keep up with all my mail, so I'll quit while I'm ahead :)
Move GMT from sci-misc to sci-data? There is a discussion about that on mail science list. I belive that sci-data was the conclusion of that.
Created attachment 46012 [details] sci-split.txt - List of "app-sci" applications split into smaller categories Thanks for your comments. Here is what I changed in this updated list: I put "kconvert" in "sci-calculators". (It is very much like kunit, which is also in that category.) > 1. I would put beagle with gaul; both are "evolutionary computing" > libraries. You are right. Both should be in "sci-libs". (I should be ashamed: I did not even know Open BEAGLE, and it is developed at my university...) > 2. The mars rover and lightspeed packages probably belong in astronomy. I agree for the mars rover packages, but not for the lightspeed package. Special relativity can be discussed without talking about astronomy. > 3. Do you want to move R from "dev-lang" to math? It certainly could fit in either category, but since all languages in Gentoo are kept in "dev-lang", I think I will just leave it there. > 4. I'd put tilp with the calculators. Yes. I was thinking "programs which behave as calculators", but it makes sense to include programs which serve as interfaces for calculators. > 5. Should "chessbrain" be in a "games" category? I do not think so. Chessbrain approches the game of chess from a mathematical and computational point of view, not from the point of view of entertainment. > 6. gempak and vis5d belong together, I think. I would trust nerdboy/mr_science's opinion for this one, and leave it in "sci-data". > sc-libs should probably add hdf(4), hdf5, netcdf, udunits, and the others > already mentioned (some are in the new list already). All these are already in "sci-libs". What are the "others already mentioned"? I probably missed those suggestions. > please move [geography packages in sci-misc] back to it's own category, > perhaps sci-geo I have no problem with creating a "sci-geo(graphy)" category, but maybe this should be done in the future. "grass", "gmt", "vis5d+" and "gempak" are the only (non libs) packages related to geography in Portage. ("shapelib" and "proj" would be part of "sci-libs".) "pcl" does not seem to have anything to do with geography. Am I mistaken, or are you talking about another package with the same name waiting in Bugzilla? "gdal", "ogr", "mapserver", "zmapserver", "zco", "ldm", "openev", "vtp" are missing from Portage. When (if) they are added, we will want to create a new category. Right now, however, the category would be too small. > Move GMT from sci-misc to sci-data? Sure. However, when (if) a geography category is created, it would probably make sense to move it there (along with "vis5d+")
Created attachment 46084 [details] sci-split.txt - List of "app-sci" applications split into smaller categories There were a few mislabeled categories in my last list...
Yes, some of the geography and earth science tools are not yet in portage (but are on the top my main list of new ebuilds to add). This will happen very fast as I work on my new geography web server project for school (gdal is just about finished). I also found another mapping package (ogdi) that is not in your list. Which brings up another point: it seems to me that geographic libs should also be grouped with sci-geo packages. Sci-libs just seems too generic for stuff like proj, gdal, ogdi, etc. That would also make sci-geo much bigger with existing packages already in portage.
Created attachment 46313 [details] sci-split.txt - List of "app-sci" applications split into smaller categories Thanks for the tip, Steve; I added ogdi to "sci-libs". Since you insist and expect the category to grow quickly (and I do not oppose that much), I created the "sci-geo" category. I also added the list of earth sciences related applications you provided to give an indication of the projected growth of the category. I also reinstated "sci-astronomy", since it has a dozen packages, which is more than "sci-geo". I think all libraries should be kept together, even if they cover a broad range of disciplines. It will be more consistent with how "media-libs", "net-libs" and "x11-libs" are structured. For instance, "media-libs" contains both sound and graphics related libraries, even though there are "media-gfx" and "media-sound" categories. It would allow to keep only end-user programs in categories other than "sci-libs", making them easier to browse for people searching for end-user software. Developers will find development libraries in "sci-libs". I have trouble with the "sci-data" category. Abstract data manipulation is hard to define. (Exactly how abstract does it need to be? And plotting programs do not even manipulate data; they are data representation programs.) Also, it ends up overlaping with other categories, such as "sci-geo" (gmt and vis5d+). It is pretty small too, with only twelve packages, so I merged it with "sci-misc" and "sci-geo". Anybody objects? Should the plotting programs be in "media-gfx" (like grace is) but maintainted by the sci herd? I will announce our intention to split "app-sci" on gentoo-dev on monday unless there are other suggestions to improve the current list by then. I expect some developers to complain about the size of "sci-geo" though.
Generic plotting programs ought to go in media-gfx, IMO. opendx is another one that's already there.
Created attachment 46316 [details] sci-split.txt - List of "app-sci" applications split into smaller categories Put plotting applications in "media-gfx".
I have started moving packages, beginning with biology related applications.
I'm updating gempak atm, so could you hold off on sci-geo for a bit?
K, done.
I am done with "sci-biology". I will continue with "sci-astronomy" and plotting packages later.
I am done with "sci-astronomy" and the plotting packages. I also found "x11-misc/tkseti" (missing from our list) that I moved to "sci-astronomy". I will continue with "sci-calculators" and "sci-chemistry" later and tomorrow.
A minor point. sci-geo(graphy or sciences)? I believe that geosciences is more clear to include areas as oceanography, meteorology and the geography.
> sci-geo(graphy or sciences)? Great! I disliked "sci-geology" too. It seemed too narrow, but it was the best I could think of (and it is sometimes used to refer to earth sciences in general). "sci-geosciences" is a lot better (if a bit redundant). Unless other devs oppose, I will use geosciences rather than geology. Thanks.
Done with: sci-chemistry sci-calculators sci-electronics sci-misc I will continue with "sci-mathematics" tonight or tomorrow.
Done with "sci-mathematics". I will do "sci-libs" next.
"sci-libs" and "sci-geosciences" are done. The reorganisation is complete, with the exception of the blas and lapack packages, which I will move tomorrow.
Done.
