Last post on this.
On Mon, 24 Mar 2003 16:24:24 -0600
Jamin Collins <jcollins@asgardsrealm.net> wrote:
> Epochs currently serve a different purpose, one that is needed. Doing
> what you propose would remove that functionality.
Bleck, you're right, brain fart.
> > > Actually, it was. You seemed to indicate that the packages for gimp
> > > should be called "gimp" and that there is no reason for version
> > > numbers in the package name. I've provided several examples of when
> > > it is needed (the above included).
> > No, you have provided an example on why there needs to be a reason to
> > differentiate between versions without having an update from one to
> > the other. You have not provided an example on why that functionality
> > must exist solely as a version number on the end of a package.
> I've never claimed that it *must* exist *solely* as a number on the end
> of the package, but simply that doing so *does* provide the desired
> functionality within the existing system. Perhaps you should go back
> and re-read my statements.
Just as I have never claimed that the example you've given doesn't happen.
You gave an example of why a resolution is needed. Fine, great, I get that.
I'm simply pointing out that the resolution given has problems.
> > IE, what should happen is this:
> > gimp 1.2
> > gimp 1.3
> > The user gets to pick which he wants; mechanisms left to the
> > imagination of the reader depending on the tools they use.
> There's that *vague* "it just works" suggestion again. Once again, I
> ask you, how?
Uhm, how does it do it now. *points to aptitude example given a few
messages ago.* Aptitude is perfectly capable of recognizing different
versions of the same package and letting the user mix between the two. Apt
can do the same. In fact from what I've read apt is capable of doing it both
on the "hard" version numbers and "soft" release names. IE gimp=stable would
be viable.
Clearly the tools are completely capable of handling multiple versions.
So what is wrong with my vague "it works" suggestion? Esp. when I have
clearly stated "an extra field to separate different incompatible versions".
I had thought epoch would work but I was having a brain fart moment forgetting
epochs are to force a backwards shift.
So how hard is it for you to put the two together? Fine, an extra field,
let's call it a strain.
strain: 0
Anything in strain 0 can be updated to a later in the same strain. If
there is a break in compatibility.
strain: 1
This would result in two entries in package manager front-end as shown
above. We could try to get by with another dancing hack and say "the lowest
strain is the one that is installed by default" since it would cover pretty
much every instance of version numbers in package name to date. IE...
exim v3.x - strain 0
exim v4.x - strain 1
bind v8.x - strain 0
bind v9.x - strain 1
However we get into a problem when we'd move up in the versions but
provide older packages for compatibility. So we could just have the field be
dual purpose.
strain: 0:default
strain: 1:optional
So if a person does an "apt-get install exim" for the MTA they would get
the default but could define the later version. On an upgrade it would check
the strain and only update in that path. At any time the default could move
to another strain if an acceptable update was made. Finally all strains would
be considered conflicts with all other strains of the same package
automatically.
Depends would not have to worry about strains. They worry about packages
first, versions second. IE if a tool were able to work with both exim v3.x
and exim v4.x (log processor for example) the depends would be "exim".
However a too that only works on 3 would add <=3.foo if denoting a specific
number or just simply <4 to exclude the higher versions. Whatever, I've not
looked into that part in great detail.
> I'm not an expert, but I would think the new version of (as you put it)
> "KDE which stomps on all previous dependencies". Why? Because it could
> make use of the Provides field.
Which is to be spammed with all previous versions of KDE since they seem
to be in the habit of releasing each new version with the version number in
the package name?
> It's not inconsistent. As myself and other(s) have shown you, there are
> a number of packages that already use this method.
Which does not point to consistency. A number of packages don't use it.
Some packages do.
Some packages don't.
Isn't that pretty much a definition of "inconsistent". As was pointed out
share libraries are the exception since, by policy, they have to have the
version number in the package name. This is, to me, consistent and I have no
complaints about it.
> As I've stated previously, it's not inconsistent. It may not be
> perfect, but it *does* work.
And as I have shown it is inconsistent.
> Which package would you install to get vnc? Is it confusing because
> it's name is not "vnc"?
Amazingly enough vncserver, xvncviewer & svncviewer don't have the
version numbers in them. Oddly enough I find "vncserver" pretty much what I
would expect especially since it is vnc and is, well, the server. This is
also consistent with Debian's other services which offer the option of
installing either the server or the client in separate packages.
> How about which one to install to get the
> version of vnc with the tight vnc extensions for testing?
tightvncserver being, well, the tightvnc server.
> Now, which one would you install in the stable release to get the tight
> extensions? Face it, package names change as they need to.
vncserver since for some odd reason the maintainer thought packaging tight
as the baseline vnc was cute. I wasn't pleased about it then nor am I pleased
about OpenSSH being passed off as SSH from Woody(?) on to the present day.
What does any of that have to do with version numbers in the name since
none of them have version numbers in the name. In fact such practices only
heighten the awareness on why version numbers in the name are a bad thing
since in one case the version numbers kind of match up where in the other they
do not. Of course that is also one of the reasons why epoch came about.
--
Steve C. Lamb | I'm your priest, I'm your shrink, I'm your
PGP Key: 8B6E99C5 | main connection to the switchboard of souls.
| -- Lenny Nero - Strange Days
-------------------------------+---------------------------------------------
Attachment:
pgpO4stpCOzG1.pgp
Description: PGP signature