Em 06-04-2010 19:40, Michael Jennings escreveu:
> 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.

You're already confusing things, please devote some time to think about
the issue because I'm not discussing against the current method, I like it.

I'm just pointing out the need to detail it further than per day so it
suits even better.

What is *NOT* sane is using "rpm --force -ivh package.rpm"

> 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.

And what I ask does not change that, but allows the period to be small
enough to allow  1) build, 2) install, 3) test, 4) fix, go to 1) process
by specifying further the hour and the minute.

>> 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

It's not so frequent to make multiple releases of software per day, so
many automatize a daily snapshot. Because some haven't run into this
issue, that does not make it a standard, much less mandatory as you seem
to argue for.

You accuse me of making up statistics, but argued against them with made
up statistics yourself, that's not fair.

I never expected such an emotional opposition.

Again: I have no intention of treading on your toes, you're making it
personal and I have more than once pointed out that there is nothing of
the such.

Rui

------------------------------------------------------------------------------
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
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Reply via email to