Re: Official Exim 4 package
On Mon, Mar 24, 2003 at 12:43:19PM -0800, Steve Lamb wrote:
> On Mon, 24 Mar 2003 13:35:34 -0600 Jamin Collins
> <jcollins@asgardsrealm.net> wrote:
> > 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.
>
> Which is different than changing a package name... how?
Epochs currently serve a different purpose, one that is needed. Doing
what you propose would remove that functionality.
> I think you made my case better than I ever could. Thanks.
You just don't "get it" do you? Packages with different names be, it
the inclusion of a numeric reference to the releases version (or
otherwise) *are not* supposed to upgrade previous versions of the
package under a different name. That's how it works. This *is*
intended. However, epochs *are* supposed to upgrade previous versions
of the package. This *is* how it works. You're recommending breaking
epochs to serve the same purpose as changing the name of the package.
1) There is no need for this as the functionality already exists.
2) The change would remove functionality.
> > 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.
> 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?
> > 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.
>
> Which would be, what? The package that was created before the latest
> named version of KDE came down the pipe or the the latest named
> version of KDE which stomps on all previous dependencies?
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.
> > 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.
>
> Pardon me for being forward thinking and despising inconsistency in
> one package.
I'm not attacking you. I'm simply stating that your claimed confusion
for users doesn't appear to exist, at least not to the degree that your
statements would seem to indicate.
It's not inconsistent. As myself and other(s) have shown you, there are
a number of packages that already use this method.
> > 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.
>
> Asking the user to use a search feature to find a package because it
> is named inconsistently with the vast majority of other packages *IS*.
> It is a kludge to get around a problem.
As I've stated previously, it's not inconsistent. It may not be
perfect, but it *does* work.
Which package would you install to get vnc? Is it confusing because
it's name is not "vnc"? How about which one to install to get the
version of vnc with the tight vnc extensions for testing? Now, which
one would you install in the stable release to get the tight extensions?
Face it, package names change as they need to.
--
Jamin W. Collins
Reply to: