Re: Package naming conventions

Dear all,

I agree with Raphaël. We cannot have two naming conventions for technical
reasons. It is not possible to change the version of an RPM at file system
level. Furthermore, users should be able to install from snapshots, then
upgrade with beta, then install snapshots, etc...

Cheers,
Jean-Michel

On Friday 08 August 2003 15:52, Raphaël Enrici wrote:
> I Totally agree with Dave. But don't you think we could go further ? As
> you just renamed files, the informations concerning the packages are
> still what they were when it was released :
> for example :
> rpm -qpi pgadmin3-0.9.0.i586.rpm
> Name : pgadmin3 Relocations: (not relocateable)
> Version : 0.9 Vendor: (none)
> Release : 20030806 Build Date: Wed Aug 6
> 18:28:01 2003Install date: (not installed) Build Host:
> mandrake.translationforge.com
>
> So, this is still pgadmin3 version 0.9 release 20030806 which is the
> same versionning scheme as snapshots releases (I took a rpm because I
> don't know anything about slackware and freebsd packages). Shouldn't the
> packages be built again with right versions ? IMHO it's not really
> important for beta releases but why not trying to do now what we will
> have to do for the final release ? By this way, we will ask us the good
> questions now and not for final release.
>
> Just for information and critics from you friends, here is what I did
> for Debian packages (and which may be used for other packaging system),
> I'm REALLY open to any corrections concerning this :
> - snapshots releases are versionned like this :
> pgadmin3-x.y.z-0.m+cvsYYYYMMDD-n whith x.y.z equal to pgadmin3 version,
> m and n minor releases number concerning the package itself.
> - beta and future stable releases are versionned like this :
> pgadmin3-x.y.z-0.m
> The "0" in the package release part is imposed by the fact that these
> packages are not official debian one and will become "1" and further
> when integrated in Debian (Think it's a good thing that could be adopted
> by other packagers ?)
> Note that I think that the beta and future stable package releases will
> live their own life (corrections, etc...) independently from snapshots
> releases (I mean in a package point of view).