At 17:58 Uhr -0500 04.03.2003, Kyle Moffett wrote:On Tuesday, Mar 4, 2003, at 17:35 US/Eastern, Justin Hallett wrote:I'm about to release proftpd 1.2.8 final and RC2 is in unstable ATM and
this is what I'm gonna do, unless someone objects in the next hmm 30
minutes :)
Current: 1.2.8RC2-1 New: 1.2.8-Final-1
I don't think that will work, as 8RC2 > 8 from dpkg's point of view. This should
have originally been done as
%v=1.2.7.9999 %r=1.2.8rc2-1
or
%v=1.2.8 %r=0-1.2.8rc2-1
Oh well, I guess that this one does need the Epoch: field set to 1, but don't post
it yet, I could be mistaken.
OTOH, a better solution to packages like this is as follows: We add a special package 'fink-downgrades' that includes scripts to downgrade certain packages that have versioning errors. Then we could almost completely avoid the Epoch: field. IE:
Developer Bob accidentally puts foo-1.2.3rc4-1 into cvs (As opposed to foo-1.2.3-0.rc4)
User George builds and installs foo-1.2.3rc4-1
Developer Bob finds his mistake and fixes the version.
The dpkg for User George thinks that it has the latest version
Developer Bob submits a request for an addition to the fink-downgrades package
User George updates his fink-downgrades package, whose install-script does 'fink install foo-1.2.3-0.rc4', then 'rm /sw/fink/10.2/debs/foo-1.2.3rc4-1......'
So essentially, you are suggesting to introduce another technique to solve a problem, just to avoid using epochs, which were made to fix exactly this problem? I fail to see the logic in that :-)
Exactly, I think that the 'epoch' system is very problematic. Once a package begins using an epoch, it must continue to use the epoch for the remainder of its life, which could be very long, even after many version changes. Epochs can be used for now, but I just had an even better idea that could be implemented in the new dependency engine (Doesn't need to be). I think that a developer should be able to specify a "VersionHistory" field in the info file that dictates versioning changes in the package, which fink could then use to work around dpkg. With something like this, only numbering scheme changes since the last stable release need be included. The dpkg epoch docs say that epochs should be avoided if at all possible, and I think that a solution like this may make the epoch system (Within fink at least) obsolete.
EX: Original package Package: foo Version: .1.1 Revision: 3
Later version Package: foo Version: 1.1 Revision: 2 VersionHistory: .1.1-3
Last version Package: foo Version: 0.1.1 Revision: 1 VersionHistory: .1.1-3 1.1-2
Cheers, Kyle Moffett
-----BEGIN GEEK CODE BLOCK----- Version: 3.12 GCM/CS/IT/U d- s++:- a16 C++++>$ UB/L/X/*++++(+)>$ P+++(++++)>$ L+++(++) E W++(+) N+++(++) o? K? w---(-) O? M++ V? PS+() PE+(-) Y+ PGP? t+(+++) 5 X R? tv-(--) b++++(++) DI+ D+ G e->++++$ h! !r-- !y? ------END GEEK CODE BLOCK------
-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com
_______________________________________________
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel
