Hello,
a friend of mine always builds the Debian Packages from unstable for
Debian Etch. I have on all my machines the following line in
/etc/apt/sources.list:
deb http://rmdir.de/~michael/git/ ./
apt-get update; apt-get dist-upgrade
and you're up2speed.
If you don't trust that packages it is very easy to build them yourself:
wget http://ftp.debian.org/debian/pool/main/g/git-core/git-core_1.5.2.1-1.dsc
wget http://ftp.debian.org/debian/pool/main/g/git-core/git-core_1.5.2.1.orig.tar.gz
wget http://ftp.debian.org/debian/pool/main/g/git-core/git-core_1.5.2.1-1.diff.gz
dpkg-source -x git-core_1.5.2.1-1.dsc
cd git-core-1.5.2.1/
fakeroot debian/rules binary
It runs the whole test suite and only contiues producing debs if they're good
to go. It might be possible that you have to install some build dependencies by
yourself. If some new git version hits unstable you can get the references for
the three files above from:
http://packages.debian.org/git-core
=> unstable
=> scroll to end of page
=> Source Packages
=> Source Package: git-core, Download: [dsc] ...
Thomas
Hello Pierre,
> FWIW there is even simpler: I maintain a backport on
> http://www.backports.org. Which is a semi-official service driven by Debian
> Developers.
good to know, maybe I am going to use backports in the future.
Thomas
On Mon, Jun 18, 2007 at 10:27:41PM +0100, Pierre Habouzit wrote:
> FWIW there is even simpler: I maintain a backport on
> http://www.backports.org. Which is a semi-official service driven by Debian
> Developers.
It seems that this is only for etch (and sarge).
I run a mixed Lenny/sid machine here. It doesn't necessarily
work when I start to install things for etch. Certainly not
once testing upgrades its libc. Or?
--
Carlo Wood <[email protected]>
On Mon, Jun 18, 2007 at 11:25:24PM +0200, Thomas Glanzmann wrote:
> Hello,
> a friend of mine always builds the Debian Packages from unstable for
> Debian Etch. I have on all my machines the following line in
> /etc/apt/sources.list:
>
> deb http://rmdir.de/~michael/git/ ./
FWIW there is even simpler: I maintain a backport on
http://www.backports.org. Which is a semi-official service driven by Debian
Developers.
Cheers,
--
·O· Pierre Habouzit
··O [email protected]
OOO http://www.madism.org
Hello,
> It seems that this is only for etch (and sarge). I run a mixed
> Lenny/sid machine here. It doesn't necessarily work when I start to
> install things for etch. Certainly not once testing upgrades its libc.
> Or?
true. But when you run sid you get a newer version of git automatically.
Sooner or later. And you can always build it yourself. It's a pain in
the ass until you have all build dependencies installed and all the
tests pass. Most of them you can get by typing:
apt-get build-dep git-core
But after that it is very straight forward.
Thomas
Hello,
* Thomas Glanzmann <[email protected]> [070618 23:56]:
> > It seems that this is only for etch (and sarge). I run a mixed
> > Lenny/sid machine here. It doesn't necessarily work when I start to
> > install things for etch. Certainly not once testing upgrades its libc.
> > Or?
> true.
I guess not so true. Because debian had always compatibility libs. So I
guess when they bump the libc revision on sid, they provide a compat
library at the same time so that you're able to run the old binaries.
But don't nail me down on this one. But for the mean time you should be
good with the packages I provided in the previous e-mail for sure.
Thomas
On Mon, Jun 18, 2007 at 11:56:10PM +0200, Thomas Glanzmann wrote:
> true. But when you run sid you get a newer version of git automatically.
> Sooner or later. And you can always build it yourself. It's a pain in
> the ass until you have all build dependencies installed and all the
> tests pass.
Oh, I already build it before my previous post :p
I just did:
sudo apt-get install libz-dev asciidoc xmlto libexpat1-dev subversion unzip tcl8.4 libsvn-perl libcurl3-dev
after having a peek at git-core_1.5.2.1-1.dsc, and then it did build
just fine immediately.
--
Carlo Wood <[email protected]>
Hello,
> after having a peek at git-core_1.5.2.1-1.dsc, and then it did build
> just fine immediately.
good point, that makes sense. I have to keep that in mind. Last time I
looked at the failed tests, saw the missing dependency and tried again.
:-)
Thomas
On Mon, 18 Jun 2007, Thomas Glanzmann wrote:
> Hello,
> a friend of mine always builds the Debian Packages from unstable for
> Debian Etch. I have on all my machines the following line in
> /etc/apt/sources.list:
>
> deb http://rmdir.de/~michael/git/ ./
>
> apt-get update; apt-get dist-upgrade
>
> and you're up2speed.
>
> If you don't trust that packages it is very easy to build them yourself:
Is there some way you can feed that into Debian please? Why the go around
through a separate repository? The maintainer of git-core is not actively
maintaining the package?
> Is there some way you can feed that into Debian please? Why the go around
> through a separate repository? The maintainer of git-core is not actively
> maintaining the package?
No. The current version of git in Debian is 1.5.2.1, a little out of
date from the current 1.5.2.2 but not too bad. However, Debian Etch
was already released with an older version of git. Debian
testing/Lenny (the next release, which is still being developed) does
not have the latest version of git yet because it is blocked waiting
for the next version of curl as well as a few other problems.
- R.
Hallo,
> Is there some way you can feed that into Debian please? Why the go
> around through a separate repository? The maintainer of git-core is
> not actively maintaining the package?
it already is. But Debian Etch is stable which means there will no newer
version of git in Debian Etch. Currently it is 1.4.whatever. When the
next stable release is released, which takes some time with Debian,
there will be a newer version of git shipped with it. So for the moment
you have to a few choices to live with when you use Debian stable:
- Use the old git version 1.4
- Build a newer version yourself
- Use the backports or any other prebuild but up2date packages
For me it was unacceptable to use git version 1.4 since the pacing of
git is very fast. So I follow the stable releases of git very close. And
as a result I update all my personal machines, the all the machines at
university and the machines I use at work with a recent git version.
Thomas
On Tue, 19 Jun 2007, Thomas Glanzmann wrote:
> it already is. But Debian Etch is stable which means there will no newer
> version of git in Debian Etch. Currently it is 1.4.whatever. When the
> next stable release is released, which takes some time with Debian,
> there will be a newer version of git shipped with it. So for the moment
> you have to a few choices to live with when you use Debian stable:
>
> - Use the old git version 1.4
> - Build a newer version yourself
> - Use the backports or any other prebuild but up2date packages
The other choice that we developers usually make is to run either testing
or unstable. "stable" is a synonym for obsolete ;-).
Christoph Lameter wrote:
> On Tue, 19 Jun 2007, Thomas Glanzmann wrote:
>
> The other choice that we developers usually make is to run either testing
> or unstable. "stable" is a synonym for obsolete ;-).
>
>
I'm just not going to let this go. Stable is synonymous with, well
ummm, "stable." That means that I don't have 3000 changes a month, it's
secure and the unexpected doesn't happen. It means I can write a
lecture explaining how git works. ...do updates... then expect my
lecture to still work the next day. It means writing local shell
scripts and expecting them to work until the NEXT stable release without
changes. It means knowing what things WILL break if and when I do go to
the next version.
Stable is a CHOICE not a punishment.
--
Jeffrey Hundstad
PS. Running unstable on my laptop... and running stable on my servers.
On Jun 19, 2007, at 19:37:51, Jeffrey Hundstad wrote:
> I'm just not going to let this go. Stable is synonymous with, well
> ummm, "stable." That means that I don't have 3000 changes a month,
> it's secure and the unexpected doesn't happen. It means I can
> write a lecture explaining how git works. ...do updates... then
> expect my lecture to still work the next day. It means writing
> local shell scripts and expecting them to work until the NEXT
> stable release without changes. It means knowing what things WILL
> break if and when I do go to the next version.
>
> Stable is a CHOICE not a punishment.
With that said; Debian makes it easy to selectively install testing
or unstable packages by adding "testing" or "unstable" to your
sources.list and putting this in /etc/apt/apt.conf:
APT::Default-Release "stable";
Then all apt-based programs will prefer stable packages everywhere
possible. If you explicitly run "apt-get install somepackage/
testing", then it will install the testing version of that package
and continue to auto-upgrade it as testing receives updates.
Alternatively, you can "man apt_preferences" and tweak your "/etc/apt/
preferences" file to your heart's content. This includes things like
"Forcibly downgrade packages to the 'local' version if found in my
local deb repo", "Prefer stable over testing and unstable", etc.
Cheers,
Kyle Moffett