William L. Thomson Jr. said the following: > > Well that's the problem. When I use say _pre instead of _dev it gives > off the wrong impression to users judging package by it's name. Since > it's not a pre-release. A user may go upstream looking for some sort of > pre-release. Which they won't find. > > The whole point is to make it clearer to the user the relation of the > sources to upstream. Instead of making them fit into our naming schema, > which do not apply to all. <snip> > The whole idea is better clarification to the end user via package name. > Instead of package being tagged as _pre or etc, and sources being tagged > with -dev and/or coming from a developers space. Not main project > release page or etc. > Hi guys,
As one of the aforementioned users, I think the goal of helping us get a better idea of the "reliability" a given package is excellent. I was looking at the GLEP list the other day, and one of them that I liked in particular was GLEP 46. (Allow upstream tags in metadata). I think it could have some bearing on this goal. Although the GLEP doesn't list "upstream-version" as one of its proposed metadata tags, I think it could fit in nicely. I have no clue what the status of that GLEP is, but maybe the authors would? Personally, I think it sounds like a good flexible way of adding information to an ebuild without needing to redo the naming scheme, or the upgrade path. Here, you could use one of the existing ways of naming the package, but in the metadata give the information a user would want to evaluate the package's reliability (plus more!) :) -nkm -- gentoo-dev@gentoo.org mailing list
