On Sat, 22 Mar 2003 20:49:43 -0600 "Jamin W. Collins" <[EMAIL PROTECTED]> wrote: > Not what you *stated*, but it was rater effectively implied. The > indication was (at least to me) that you were saying the notices were > ignored and therefor rather useless.
Which they are. That does not translate into "they should be removed."
Modified so as to not bother the user when a compatibility break doesn't
happen. Yes. Removed, no.
> And, as I've already stated, v4 could be packaged in such a way that it does
> not directly upgrade v3. Thus, it would *not* be a /base/ package.
Which is inappropriate, IMHO.
> Because my response was not related to it. But since you seem to really
> want me to address it, I see no problem with major changes like this
> taking this route. It allows the end user to choose what /they/ want.
Why would an end user want to choose such an older version over the
current version?
> > We have a version number field for a reason yet more and more we now
> > have the version number in the name which is getting annoying. Do we
> > really need exim and exim4? Shouldn't it have been exim3 right away?
> > Should we go through and add major version numbers to every package?
> When necessary sure. Your definition of /necessary/ will not
> necessarily be the same as mine.
It does. See below.
> > I think it would be mistake if it weren't. Not without some change
> > that makes it clear when we put version numbers in the name and
> > when/if we don't *or* that something gets into place on the version
> > number field to address this so we don't have to remember to add the
> > major on this package but not on that package.
> Matter of preference. There are a number of packages in Debian with
> their version (or some other indication of their version) in their name
> already.
Yes, it is a matter of preference. However, since when was preference a
matter of /policy/. I am pointing out that there appears to be no policy in
regards to when a version number is attached to the name of the package. The
problem is that we now have packages which just the name works
(sylpheed-claws) and other packages where one needs to include the version
number to the major number (bind9) and others to the minor or revision
(libssl0.9.7). This is a problem because one doesn't know when to include the
version number and when not to as there is no consistency. Enforcing
consistency is a matter of policy, not preference! Policy can stem from
preference but only when one can explain why that preference should be forced
upon others in a logical, clear and concise manner.
My beef is that we already have a place for version numbers. Here:
Package: libssl0.9.7
Status: install ok installed
Priority: standard
Section: libs
Installed-Size: 4801
Maintainer: Christoph Martin <[EMAIL PROTECTED]>
Source: openssl
Version: 0.9.7-4
^^^^^^^^^^^^^^^^
I am interested in installing libssl. We have three packages replace it
but none are named libssl. In fact the latest version doesn't show up
as a replacement as all. Great, now I need to investigate which version I
need to install. But wait, isn't one of the points of the packaging system to
remove the need to know exactly which version of this package and that package
to install? I sure thought it was.
Obviously there is a problem where some packages are breaking
configuration compatibility and a way to keep two separate versions around
without upgrading from one to the other happens often enough it needs to be
addressed. However I don't think simply adding the version number into the
package name is appropriate since the problem is in how the Version field is
handled. It is a hack to get it to work. It isn't a hack to base policy of
future compatibility on. And while your preference is to have it so you can
have your pet package in the distribution right now do you really want to
encourage such sloppy behavior for future releases? It is already a mess. We
don't need more of the same.
That is unless, of course, I am mistaken that there is some policy to
cover this. If there is I'd be interested in someone pointing it out to me
and explaining why we have packages without version numbers, packages with
only majors and packages with major, minors and revisions in the name. I see
no consistency which points to a well-written policy on the subject.
--
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
-------------------------------+---------------------------------------------
pgp00000.pgp
Description: PGP signature
