On Tuesday, 06 April 2010, at 14:38:36 (+0100), Rui Miguel Silva Seabra wrote:
> I'm sorry, but that breaks the whole point of having clean software > installs. How, exactly? > It's definitely *not* a sane (in terms of package DB) replacement to the > proper usage of the release field. There is nothing improper about the current usage of the release field. Said usage varies radically from distro to distro and even from package to package within the same distro. Its purpose is to provide an additional mechanism for distinguishing packages which may correspond to an identical upstream version. Beyond that (and not containing a hyphen), it's open season. The current method was chosen to simplify things for those building periodic snapshots from SVN. It serves that purpose very well by providing the date of the snapshot in a readily readable, sequencable form which (thanks to the 0. prefix) does not interfere with the eventual release of the version in question. > As can be read from the man page, it can even have dangerous results: > > --force > Same as using --replacepkgs, --replacefiles, and --oldpackage. > (...) > --replacefiles > Install the packages even if they replace files from other, > already installed, packages. I never said you should use it all the time. I said in the specific case of installing a new version of an RPM that you previously installed the same day while doing active development on a particular package, using --force is a safe and easy way of accomplishing what you want (installing RPM's during development) without interfering with the other reasoning behind the naming convention. I'm on the RPM5 development team. I know exactly what --force does and when to use it. > As to the POV of users, they expect an incrementing value (which is also > what the release field should/must have precisely so upgrades can be > done sanely) and even if they don't recognize instantly date+hourmin, > they surely recognize just as instantly an increasing value, so there is > no point to raising such scarecrows. Again, these spec files are intended for building snapshots from SVN on a periodic basis, and we chose to provide something useful in the release field in the form of a snapshot date. > It's as made up statistic as claiming YYYYMMDD is a standard snapshot > format. ftp://ftp.openssl.org/snapshot/ http://www.mindrot.org/openssh_snap/ ftp://sourceware.org/pub/gcc/snapshots/ ftp://sourceware.org/pub/gdb/snapshots/current/ ftp://sources.redhat.com/pub/glibc/snapshots/ http://www.gti.net/mirrors/postfix-release/experimental/ http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=3&chap=1#doc_chap3_sect5 Michael -- Michael Jennings (a.k.a. KainX) http://www.kainx.org/ <[email protected]> Linux Server/Cluster Admin, LBL.gov Author, Eterm (www.eterm.org) ----------------------------------------------------------------------- "Somebody pass the Charmin! I'm dumping core!!" -- Black Widow 2.0.3 ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
