Re: Multiple versions of packages...
On Sun, Jan 10, 1999 at 04:38:54PM -0500, Steven Baker wrote:
> I was looking at the way some packages are named, and found one very
> disturbing trend... The naming scheme of packages is not very standardized.
> Some Glibc pcakges have a g on the end, some have version numbers, and some
> don't.
Packages that used to have a libc5 version now have the 'g' extension
in order to tell them apart (used during the bo->hamm). The number
after it is usually the so version. It's important for some libs since
version increases can cause incompatibilites, so the suffixed version
prevents conflicts until binaries are compiled agains the newer libs.
> After some thinking, I decided that a simple fix to the packaging tools would
> eliminate the need for weird version names. We could then name packages by a
> descriptive name, and not worry about foobarring the name.
> If the packaging tools were updated to allow multiple versions of a package
> to be installed, then we could fix some of the weird naming schemes going on.
Multiple versions of libraries can be very bad if not controlled by the
package. Allowing the package tools to decide this isn't good.
> I was wondering who a patch to dpkg would have to go through, and if there is
> demand for this type of thing.
Posting to debian-dpkg is a start.
> The packages that I am specifically referring to are kernel-*<version> and
> libgtk<version>
These are neccesary evils IMO. libgtk has some inconsistency, that
requires that extended version numbering.
> I think it's more confusing to look at libgtk1.1.12_1.1.12.deb
> I don't know about everyone else.
Better than looking at all the error messages from binaries that link
to the wrong lib :)
--
----- -- - -------- --------- ---- ------- ----- - - --- --------
Ben Collins <b.m.collins@larc.nasa.gov> Debian GNU/Linux
UnixGroup Admin - Jordan Systems Inc. bcollins@debian.org
------ -- ----- - - ------- ------- -- The Choice of the GNU Generation
Reply to: