Re: Duplicated/redundant package for PEAR::Message -> PEAR::Crypt_HMAC

Jesus, I think that the archiving of obsolete/unmaintained packages is neccessary, and that should a user try to install one of these packages this would happen: $ pear install old_pkg old_pkg has been deprecated for new_pkg, if you are using old code which relies on old_pkg you can use 'pear install -A old_pkg" $ with -A standing for Archive, perhaps -a though? I am still wanting Crypt_HMAC to be seperate from PEAR::Message, and to stay with its current name, or perhaps creating a Hash section for all the hash type stuff, Hash_MD5, Hash_SHA1, Hash_Digest/Hash_Message (which would rely on the two previous packages for its fall back). The reason for keeping *_HMAC is its clearer what it's using (try looking for the Digest RFC!). Similarly, starting a Hash section would make it clearer that those packages do *not* encrypt. just my 2 cents, well, more like a dime. - Davey Jesus M. Castagnetto wrote:

I agree that removing a released package is problematic, not only for the people using it, but for the PEAR approach to the discussion-voting-approval-commit-release cycle for newer packages. I was thinking more along the lines of what we use in bioinformatics for old data or programs. Most big databanks (like www.rcsb.org), have a section with 'obsolote' entries, usually indicating the reason why they were obsoleted, either a newer structure with better characteristics was released, or the original obsoleted entry was misnamed/misidentified or incomplete, etc. This would be applicable not only to cases like the one we are discussing now, but cases in which packages have been abandoned for whatever reason (lack of time from the maintainers, etc.) The solution that would be "a good thing" (IMHO) in the case of Message and Crypt_HMAC, would be to think of them as the Cache and Cache_Lite approach, with the addition that it might be better to obsolete both packages, and create a merged one with a more precise name. Hashes and HMACs generate message *digest*, they do not strictly encrypt a message (cleartext), in the sense that crypt/blowfish/etc will, as the resulting data is lossy (i.e. you cannot reconstruct the cleartext from the encoded output). The names I am thinking is the ones I proposed last year: Digest or MessageDigest. In that view Message ---> Digest, Crypt_HMAC ---> Digest_Lite Similar libs/packages in other langs that calculate an HMAC are classified in the Digest category, e.g.: http://www.cpan.org/modules/by-module/Digest/ Whereas in others it is also classified as a cryptographic hashing algorithm in others: http://www.gnu.org/software/gnu-crypto/api/gnu/crypto/mac/HMac.html http://www.python.org/doc/current/lib/module-hmac.html So the category would be OK for it to be Crypt (perhaps Crypt_Digest?) As I mentioned before, merging the packages so the lite version is kept from Derick's is quite OK with me. We will just need to sync the API, but if both our projects are obsoleted in favor a merge one that will not affect existing users of Message or Crypt_HMAC. Just to clarify. My proposal of maintaining an 'obsoleted' list of packages, means that the releases are not just removed and tossed away, they should be kept for many reasons, from people that have code using that package and need to move the code to a place that does not have the package installed, to a way of indicating that that package has been superseeded by another one and that a new user should use those. When a package gets 'obsoleted' (by express request/agreement of the developers), a reason will be noted in the package and a pointer to the newer package would be made. In the case of abandoned, something along the lines of the approach above can be done. An 'abandoned' package will be tagged as such, in that way if a developer wants to contribute to PEAR but does not have a idea of what to write, he/she can peruse through those and perhaps find a project that he/she will be happy to maintain. Ideas? Comments? --- Lukas Smith <smith@backendmedia.com> wrote:

From: Pierre-Alain Joye [mailto:paj@pearfr.org] Sent: Friday, April 25, 2003 10:31 PM

On Fri, 25 Apr 2003 21:14:59 +0200 "Lukas Smith" <smith@backendmedia.com> wrote:

Removing is not an option, as 1) it was downloaded by 267 people who might now depend on it [1]

This cannot be a reason. Otherwise we would be setting a horrible precedent.

This is a valid reason. And you (the community) let a far more

horrible

precedent recently set here. The problem was while the package has been commited and released, removing now is not a good solution, like removing the most horrible precedent I never seen in PEAR.

So anyone can just submit a package and we will not remove it if there have been a number of downloads? Seems to me it makes since way to easy to just throw things into PEAR, by mistake (forgetting to ask) or even on purpose. Regards, Lukas

===== --- Jesus M. Castagnetto (jcastagnetto@yahoo.com) Research: http://metallo.scripps.edu/ Personal: http://www.castagnetto.org/ __________________________________________________ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo http://search.yahoo.com