[...]
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.
I doN't see the problem with this, really, it's just one field. What exactly is the drawback of having that field around "forever" ? The same holds true for many other fields, too (Maintainer, Homepage, License, etc.). However that doesn't mean I insist on using epochs for this, I just don't follow yours and Ben Hines' logic. <shrug>. The fudging approach Benjamin Reed suggested sounds very viable. Contrary. the 5.0-rc -> 4.999-rc sounds like shit (and no Kyle this is not meant as an assault at you, I perfectly understand you gave it as an example as to what has been done in the past, and I appreciate that even - I just think the 5.0-0rc1 writing is much more "user friendly" :-)
So, I think this approach is good. It's not useful for fixing up old version mistakes, though, only for the future.
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.
This sounds like a horrible hack, I really don't like it in any way. It means we have to abuse dpkg; we have to considerably increase the complexity of FInk; package maintainers have to learn yet another comparatively complicated concept; and maintaining this list requires a lot of care and work.
It's not quite clear how you meant the work around to be working: if you menat fink should fake the versions in the .debs, this would be extremly evil, because then the versions reported by dpkg / apt wouldn't match those reported by fink anymore , in my eyes the worst problem which on its own rules this approach out in my eyes.
If OTOH you means this should be used by fink to install the specific version fink considers to be latest as opposed to what apt-get / dpkg think is the latest, this is extremly evil because it means that no non-fink dpkg based tool (apt-get, primarily) could be used anymore to manage a Fink installation.
Max
-------------------------------------------------------
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
