Re: PyVault Nomenclature

Jeff Pitman <[email protected]> Mon, 10 May 2004 08:18:01 +0800
Newsgroups gmane.linux.redhat.rpm.atrpms.repo-coordination
Message-ID <[email protected]>
On Monday 10 May 2004 01:03, Axel Thimm wrote:
> just a general question, do you want to extend to non-Red Hat
> distributions (in the future) or will you only consider Red
> Hat/Fedora?

Possibly. Although, I'd be hard-pressed to maintain that many.

> On Mon, May 10, 2004 at 12:20:02AM +0800, Jeff Pitman wrote:
> > For versioning, I'll try to stick with what's
> > mainstream (ie, python2.3-2.3.3-3.pyv.0.rh90).
>
> I'd suggest to move the repotag (pyv) to the end of the comparison
> string, e.g. python2.3-2.3.3-3.rh9.pyv (to make the repotag less
> important than the disttag from an rpm upgrading POV)

Arghh!  I lied to you.  It was a late night post.  This is what it looks 
like:

python2.3-2.3.3-7.rh73.pyv.i386.rpm

Now if someone can give me some enlightenment about vepoch, I'd be 
slightly interested.  But, it seems to me like a nuclear warhead 
approach to versioning.

> >   ATrpms uses a more Redhat-esque approach by naming every package,
> >   regardless of its role, closer to the original package name as
> >   distributed by the original Python package.
>
> That's a general stance, not only for python. I try hard to respect
> the authors and communities in their choice for a name and also not
> create additional external (aka deduced from a packager) confusion.
>
> It also can become a problem if a packager invents a canonical name
> and suddenly a software project emerges which carries that name.

I think that answers this question:

XXX - Do we want to simplify package naming? PyXML --> python-xml, 
PyOpenSSL -> python-openssl?

I'll shy away from that approach.

But, I still wonder about these:

XXX - Do we want all lowercase, or bumpy text matching original package 
name?

XXX - Upper or lower case?

> Python packaging is often compared to perl, but there are significant
> differences, perl has a rather standardized categorization of its
> modules making a canonical approach easier. Furthermore the perl
> modules don't have any indication of its own that they are such and
> could often clash with non-perl packages, which neccessiated the
> "perl-" prefix (e.g. perl-Tk, perl-GD etc. would fall into the same
> namespace with the non-perl packages w/o a prefix).
>
> The situation with python is different as almost all python
> module/library-like projects have python appreviated in their project
> name, or are rather prominent w/o a chance of a clash (like yum or
> rhlp).

Well, because of the coexistence with other versions of identical 
libraries, I will need the prefixing.  However, in light of the 
previous comment block, I'll try to match the naming of the upstream 
sources.

Your comment about other distros comes into play as well, since 
pypackage.org focused on Mandrake Cooker first and then moved into FC2. 
So, in order to share the specs better, I might just need to follow 
pretty closely to what has already been put in place.

Now, for actual applications like Zope, SCONS and Bicyclerepair, I might 
just upgrade the existing applications on the system, rather than try 
to sidestep them and put them in another directory.  But, these are 
actually a lower priority right now.

Thanks for your input.

take care,
-- 
-jeff