Re: Official Exim 4 package
On Mon, Mar 24, 2003 at 10:28:41AM -0800, Steve Lamb wrote:
> On Mon, 24 Mar 2003 11:26:38 -0600 Jamin Collins
> <jcollins@asgardsrealm.net> wrote:
> > No it's not. Version number indicate a progression of an
> > application, they have no indication of "major differences between
> > two releases". Just because a package moves from 1.x to 2.x or 3.x
> > gives no indication of any major changes. They are just version
> > numbers.
>
> But they do indicate change and part of that change can be
> incompatibility which is often, but not always, denoted by a change in
> the major number.
A lot of "can be" clauses in that statement. Thus, version numbers are
not by themselves a clear indication.
> > > A possibility would be to have the epoc denote different packages.
> > > Not have the packaging system update from one epoc to the next and
> > > actively list different epocs in the package list.
>
> > This could/would cause serious breakage with the existing package
> > pool. In short, not a good idea.
>
> Why? It would be an alteration, not a serious breakage. The only
> difference is that now we don't automatically upgrade on a larger
> epoc. We just consider them different.
Because epoch's already have a use, which is different from what you
describe. You're suggesting tacking new functionality on to them that
is completely different from their existing use. Thus, existing
packages using them will not function (WRT upgrades and what not) as
they once did. Thus, breakage.
> The phrase is "couldn't care less" as in one is incapable of less
> caring. Could care less is a very bad mangling that is constantly
> perpetuated without people understand the problems associated with it.
> Much like version numbers at the end of package names.
So, I typed the phrase wrong. I'm fairly certain the intent of the
statement was clear to anyone reading it. If you were somehow mislead
by it, I apologize. Perhaps now we can agree that we both understand
that I have no concern over exim's v4 packaging specifically. Rather,
I'm discussing a larger more generally issue of how to package a new
release of an application that is not compatible (for whatever reason)
with previously packaged versions?
Is that clear enough?
> > Based on that, you're using the wrong command already. You're
> > looking for a package, but using the "show" command, rather than the
> > "search" command.
>
> No, I am illustrating the problem. Change "apt-cache show" to
> "apt-get install". Install takes a package name just as show does.
> Yet this works:
>
> apt-get install pan
>
> While this does not:
>
> apt-get install gimp
Nor should it, you haven't supplied a valid package name. Supply a
valid package name and it _will_ work. There are reasons for gimp (and
other packages) having a version number in it's name.
> > gimp1.2:
> > Description: The GNU Image Manipulation Program, stable version
> > 1.2
>
> > gimp1.3:
> > Description: The GNU Image Manipulation Program, development
> > version
>
> > Note anything significantly different between the two? I sure do.
>
> Which is never in debate, now is it?
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).
> What is in debate is how that situation is handled and, quite frankly,
> how it is getting rather annoying in some cases where the package name
> is being used because of "incompatibilities" and packages that are
> dependant upon those which aren't incompatible. KDE apps and the
> constant changing of KDE to KDEx.x.x is a prime example. It gets
> frustrating when a package is unintalled because of the latest version
> of x or y comes out with yet another package name, superceding and
> conflicting with the previous yet, amazingly, if I force said package
> to install it works fine.
That's an issue to take up with the maintainer. If you can force the
install and it works fine, then quite possibly, the maintain has their
constraints too tight on the package requirements. In other words, file
a bug against the offending package.
> Yes, there are reasons to have a split. Never in question. I just do
> not believe that mangling the name is the best way, nor even a
> desirable way, to handle the situation. It causes problems, it causes
> inconsistencies, it causes user frustration.
So far, you're the only user I'm aware of that has become "frustrated"
by it. Sure, there are probably more out there, but I hardly think it's
a problem of the magnitude you claim it to be.
> I can dance around these issues no problem because I have been using
> Debian for years. However it sure doesn't help Debian's reputation at
> all nor does it help when talking to people about Debian and the
> problems they've had.
Is Debian perfect? No. Have I ever claimed it was? No. Has another
viable plan been presented? Not that I'm aware of.
> I am not saying to cater to the ignorant but certainly making things
> confusing and inconsistent isn't an acceptable goal, either, eh?
Asking a user to use a search feature is hardly "confusing" or
"inconsistent". Thus, I don't find the current situation to be either
"confusing" or "inconsistent". Quite the contrary. Debian has simply
"made sense" since I started using it.
--
Jamin W. Collins
Reply to: