Skip to Content.
Sympa Menu

freetds - Re: [freetds] package tarballs

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: Mark Brand <mabrand AT mabrand.nl>
  • To: freetds AT lists.ibiblio.org
  • Subject: Re: [freetds] package tarballs
  • Date: Thu, 28 Jan 2010 11:13:21 +0100

Thanks for the reply.

>> You never know what you'll find when you download and
>> unpack
>> http://ibiblio.org/pub/Linux/ALPHA/freetds/current/freetds-current.tgz
>> :).
>>
> I hadn't thought of that. In stable/freetds-stable.tgz is a symbolic
> link to freetds-0.82.tar.gz, but it's not done that way in current/, nor
> for freetds-patched.tgz.

Right, the current URL/filename scheme is a problem for "patched", since
there is currently no URL pointing to a particular "patched" version.

It's important to have persistent URLs to specific patched versions, not
only the latest. The obvious reason is to know what you are downloading
and the name of the directory that will be created. It also makes it
possible to use a checksum to verify the downloaded file. This is more
important than the frequency of patched versions, or whether you provide
any other sort of "pre-release" tarballs.

> I think your strongest argument is for the
> "automatic patched releases" to each have their own version e.g. 0.82.1 or
> 0.81.0.20100128.
>

A filename like freetds-0.82.1.dev.20100123.tar.gz that unpacks to
freetds-0.82.1.dev.20100123 would do the job. I think that's what "make
dist-gzip" already makes. For our purposes, the version would be
"0.82.1.dev.20100123".

Since we're on the subject, "make dist-bzip2" would be only very
slightly preferred.

> I think what you're really asking for, though, is more frequent releases.
> It's a fair point. The current ChangeLog is 2200+ lines and is two years
> old.
>

Sure, it might be nice to have more frequent releases and more frequent
releases might make what I'm asking for less necessary. But that's the
business of the project and I'm glad that the project takes release
quality seriously.

> I wouldn't want to see mingw-cross-env distribute interim unofficial
> machine-built pseudo-releases. The documentation would be out of date;
> there might be odd bugs owing to the mechanical cutoff. I very much
> believe FreeTDS should be useable from the docs, that no one should need
> to turn to the mailing list to discover a feature or confirm a bug. While
> I doubt mingw-cross-env users would flood the list with questions, at the
> same time I want their experience to be the best possible given our
> resources.
>

I'm thinking more along the lines of the "patched" version you already
have. If the URL/filename/directory issue could be fixed, we would be
pretty happy. It also helps if it's reasonably current, but that might
already be so. I see today's patched version is ".20091223".

Tarballs for alpha, beta, and release candidates might be nice in
helping distros to get ready, but that's less pressing.

> If you're mostly motivated by the latest sspi feature, you'll be pleased
> to know we've been working toward the next release for a couple of months
> now. The documentation is mostly ready -- now with a new & improved
> Troubleshooting section! -- so it shouldn't be long now. Certainly before
> spring in the northern hemisphere.
>

That's another reason to look forward to spring.

It would be up to you if the SSPI feature made it into a "patched"
version. I wouldn't be surprised if it's excluded on the grounds that
it's a new feature, not a bugfix.

It's true that my enthusiasm for the SSPI feature motivated me to write
about this, and it could be handy to have this in an alpha/beta/RC
tarball for 0.83, but the real issue is the URL/filename/directory for
the patched 0.82 tarball.

A distro can always backport desired features like SSPI, but this gets
messy when it's hard to get a known patched version of the current release.

Thanks for considering this.

-Mark





Archive powered by MHonArc 2.6.24.

Top of Page