Re: Official Exim 4 package
On Mon, Mar 24, 2003 at 03:16:37PM -0800, Steve Lamb wrote:
> Last post on this.
>
> On Mon, 24 Mar 2003 16:24:24 -0600 Jamin Collins
> <jcollins@asgardsrealm.net> wrote:
>
> 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.
I'll admit that I must have missed them then. I don't recall a single
problem being presented. Instead I've seen speculation on how it would
cause confusion. Yet, elsewhere in the Debian package system it works
just fine.
> > There's that *vague* "it just works" suggestion again. Once again,
> > I ask you, how?
>
> Uhm, how does it do it now.
This is how versions are handled currently:
http://www.debian.org/doc/debian-policy/ch-versions.html
> Clearly the tools are completely capable of handling multiple
> versions.
It's not a question of whether the tools can handle multiple versions.
It's a question of how to handle situations where a new version of the
package is not backward compatible and an upgrade to the new version
*will* break things. Thus, the system should not be automatically
upgraded to the new version.
> So what is wrong with my vague "it works" suggestion? Esp. when I
> have clearly stated "an extra field to separate different incompatible
> versions".
The lack of any indication of how to make such a system work. Not even
a high level overview (which you've finally started in this response).
> 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.
(snip)
I didn't see anything majorly broken in what you suggested. However, it
would (if I'm not mistaken) be a large undertaking and require updates
to scripts that maintain the different branches (testing, unstable,
etc). Not to meantion all of the package tools.
> 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".
I believe you've just described virtual packages.
http://www.debian.org/doc/debian-policy/ch-relationships.html#s-virtual
> > 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?
No, the packages with version numbers in their name could Provide
virtual packages without the version numbers. Then the packages that
depend on them could depend on the virtual packages.
> > 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.
Those that need it use it, those that don't do not. Not every package
has an epoch. Does that mean that epoch's are inconsistent? No. Again,
those that need it use it, those that don't, don't.
> Isn't that pretty much a definition of "inconsistent".
Inconsistent is defined (at m-w.com) as:
: lacking consistency: as
a : not compatible with another fact or claim <inconsistent statements>
b : containing incompatible elements <an inconsistent argument>
c : incoherent or illogical in thought or actions
: CHANGEABLE
d : not satisfiable by the same set of values for the unknowns
<inconsistent equations>
Of the above, a: doesn't apply (it's not a statement), b: doesn't apply
(it's not an argument), c: could apply, and d: doesn't apply (it's not
an equation).
So, looking at c:, I'd say no. The addition of a number (usually
referencing the major version of a package) to the package name in
situations where it helps prevent an automatic upgrade from breaking an
end user's system is not inconsistent, as it is not "incoherent or
illogical in thought or actions".
> 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.
Policy is a guide. Because something is not listed in policy does not
mean it isn't done or that it doesn't make sense to do it. Take a look
at the debian-policy mailing list archives.
> > 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.
Nor did I indicate that they did. You indicated that gimp was confusing
because you could not simply "apt-get install gimp". Additionally, you
seem to be against packages changing their names when needed. So, I
provided an example of an application with potentially no intuitive
names that had recently changed it's name.
Additionally, the name change of this package did cause breakage.
Systems that had xvncviewer installed prior to the creation of
xtightvncviewer were automatically upgraded to a non-tight version of
the viewer. This new version didn't understand the same command line
arguments that the tight version did. This is an example of an
automatic upgrade (without warning) that should *not* have occurred.
> 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.
A good number of these packages are named after their source with
-server or -client after them. So, are vnc's packages inconsistent?
> What does any of that have to do with version numbers in the name
> since none of them have version numbers in the name.
Nothing, that was in response to your claim that you should be able to
intuitively install a package (the example you provided was gimp)
without first searching for the actual package name.
--
Jamin W. Collins
Reply to: