Re: Official Exim 4 package
On Mon, Mar 24, 2003 at 08:14:28AM -0800, Steve Lamb wrote:
> On Mon, 24 Mar 2003 08:35:17 -0600 Jamin Collins
> <jcollins@asgardsrealm.net> wrote:
>
> > This is not just about version numbers, it's about handling major
> > differences between two releases, regardless of the change in
> > version numbers.
>
> Which is, oddly enough, part of the reason we have version numbers.
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.
> > And how does the packaging system deal with breakage between
> > versions? TMK, it doesn't.
>
> No. But clearly it is a common enough occurance that it /should/. I
> have said that a few times now.
So, make a proposal already. I have, and it will work if used.
> > If you don't like the suggestion, suggest something else. So far, I
> > haven't seen a suggestion on how to handle it other than to do
> > nothing.
>
> 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.
> > It's not my *pet* package. I could care less whether exim v4 is in
> > Debian in a month or year or more.
>
> You could care less which means you have some caring? I don't think
> that is what you meant to say.
I could be wrong here, but my understanding of that phrase has always
been more of a "lack of caring". I'm not concerned specifically with
exim and whether or not v4 is included, but rather that the reasons for
it (or any other package) not being included are sound.
> > My problem is with the reasons stated for it not being available.
> > They simply don't hold up. There are ways for it to be made
> > available without causing harm to v3 installations.
>
> Which do harm to the entire packaging system in the eyes of some.
Please read Colin's posts. The process is already in use, and works
quite well. If you don't like it, take the time to work out something
better.
> > Could have fooled me, seems to be working pretty well.
>
> Says the man who has been using Debian for years and not the newbie
> who's trying to figure out where gimp is.
I've hardly been using Debian for "years". If anything I'm a newbie. I
just take the time to try and understand what I'm using.
> {grey@teleute:~} apt-cache show gimp
>
> Or where the latest kde is....
>
> {grey@teleute:~} apt-cache show kde
Let's take a moment to look at the "apt-cache" man page:
show show performs a function similar to dpkg --print-avail, it
displays the package records for the named packages.
search search performs a full text search on all available
package files for the regex pattern given. It searchs the
package names and the descriptions for an occurance of the
string and prints out the package name and the short
description. If --full is given then output identical to
show is produced for each matched given then output identical
to show is produced for each matched package and if
--names-only is given then the long description is not
searched, only the package name is.
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.
> Oh, right, it's gimp1.2 and gimp1.3 and kde3.1.0, no wait, kde3.1.1, d'oh!
>
> That's sensible to you?
Yea, if I want gimp1.2, I don't necessary want to be "auto upgraded" to
gimp1.3. Let's take a look at them:
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.
--
Jamin W. Collins
Reply to: