pkgsrc-Users archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: History behind pkgsrc 'biology' category
In general, yes. In this case, no :( But I don't think it matters much
to the general pkgsrc user.
I dislike the situation we have now, where there are multiple choices
of category for a package. That's a personal thing, and having to look
locally as to whether a package is in time/ sysutils/ devel/ or net/
is one thing that annoys me. I find I look for everything on pkgsrc.se
nowadays, but even that has failed me where I've used the wrong
package name (pkg vs. pkgng). So I think having one place to look is,
or that springs to mind initially, is best. And I think "science"
overlaps so many of biology, math/, chemistry/, physics/. And where do
you stop? molecular-biology, astro-physics/, nuclear-medicine?
In the whole scheme of things, if we had a VCS tool that could track
moves, that would be great. But we don't, and all follow up on that
should go to tech-repository@. In the meantime, let's assume that
moving pkgsrc entries between categories (physical movement, rather
than listing tags under CATEGORIES) ist verboten, so we'll have to try
to get it right a priori.
I think, medium to longer term, it won't matter much to the vast
majority of users, as long as the right search tools are there, and as
we move to different tools (there's a lot more involved than mere repo
conversion, though). And for those search tools, a huge and resounding
THANK YOU! to the guys who do pkgsrc.se
Best,
Alistair
On 6 February 2016 at 11:07, Greg Troxel <gdt%ir.bbn.com@localhost> wrote:
>
> Jason Bacon <bacon4000%gmail.com@localhost> writes:
>
>> 2) I'd like to see a general science category. As it is now, some
>> science packages get shoehorned into math or biology. (e.g. chemtool,
>> py-scipy) Where there aren't enough packages to warrant certain more
>> specific categories, science would be a more intuitive place to look
>> for them.
>
> That sounds ok to me. I would rather add it sooner than later, because
> I think renaming packages has significant cost.
>
> Other opinions?
Home |
Main Index |
Thread Index |
Old Index