Re: [vox-tech] Installing subversion from sid into a sarge box
I'm just a monkey with a wrench here, but I created a file called /etc/apt/apt.conf.d/60defaultrelease with contents set to the line you quoted above this summer, and my system is still working. Does the numbering matter? that is, does the 60 in 60defaultrelease mean anything? I can't find any doc on it Thanks Jay ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] Installing subversion from sid into a sarge box
However, I'm always surprised at people saying they want to be on the testing track prior to release, but not afterwards. Why is that track desirable today, but not after sarge's relese? I just want the newer stuff, Perl primarily. And since sarge is almost stable seems to be the right dist for me. I'll continue on sarge for a while (couple of years, I figure) once it goes stable Jay ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] Installing subversion from sid into a sarge box
On Wed, 2005-01-05 at 11:11 -0600, Jay Strauss wrote: Does the numbering matter? that is, does the 60 in 60defaultrelease mean anything? My guess is that the number is there to control the order in which the files in apt.conf.d are read. -- Josh Parsons Philosophy Department 1238 Social Sciences and Humanities Bldg. University of California Davis, CA 95616-8673 USA Please avoid sending me Word or PowerPoint attachments. See http://www.fsf.org/philosophy/no-word-attachments.html ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] Installing subversion from sid into a sarge box
Quoting Jay Strauss ([EMAIL PROTECTED]): However, I'm always surprised at people saying they want to be on the testing track prior to release, but not afterwards. Why is that track desirable today, but not after sarge's relese? I just want the newer stuff, Perl primarily. You might want to track testing, then. More below. And since sarge is almost stable seems to be the right dist for me. It's possible that there's a bit of lingering confusion, so please pardon my going didactic (er, more didactic ;- ) on you for a while: The Debian branches named for Toy Story characters (buzz=1.1, rex=1.2, bo=1.3, hamm=2.0, slink=2.1, potato=2.2, woody=3.0, sarge=3.1, and the planned etch branch that isn't yet extant) are _starting points_ -- installable package ensembles -- for Debian systems. Absent special circumstances I can't think of at the moment, one would ordinarily want to install one of those that's in reasonable condition and useful at the date you're doing this (i.e., avoiding installing buzz/1.1 in 2005). Absent special circumstances, you would from that point forward want to choose how far away from the bleeding edge you want to be, and keep tracking that distance. Here's the thing: Remaining on woody after release (as you seem to intend) means _not_ staying the same distance from the bleeding edge. You probably don't want to do that. I'll detail why: At any given time, the package ensemble (branch) that's in best shape for running absolutely reliable systems has symlink stable pointed to it. The later branch gets symlink testing, and receives all packages newly uploaded by package maintainers, after filtering by automated quarantining by scripts that check new packages uploads against certain quality criteria. I refer to stable and testing -- functional names indicating current distance from the bleeding edge, and thus continually getting newer replacement package versions -- as tracks, to distinguish them from the Toy Story-named branches, whose names designate installable package ensembles that were put together at some fixed point in time. It's also possible to get raw access to new package uploads without quarantine delay: This is branch sid, which also bears permanently assigned track name unstable. (Thus, testing is defined as unstable, net of package quarantining.) At some point in the future (release day), woody/3.0 will get mothballed (losing the stable track symlink, which will be repointed towards sarge/3.1). A new branch will open up, called etch, which will get the testing branch symlink. And of course the unstable symlink will remain pointed (as always) at sid. After that day, systems that are set to track stable will smoothly transition, the next time the users gets package updates, from woody/3.0 package versions to sarge/3.1 ones.[1] Systems set to track testing will transition even more smoothly from sarge/3.1 package versions to etch ones. In both cases, the systems affected will _remain_ the distance away from the bleeding edge that the admin has decided is desirable. This is A Good Thing. If you define your system's default branch (in /etc/apt/[whatever]) to be testing, you're saying please keep me a few steps back from the bleeding edge, in retrieving package updates. If you define it to be stable, you're saying I'm extremely risk-adverse and/or short on download bandwidth, so I want only extremely well-tested versions of everything and don't mind using relatively antique versions. Setting your default branch to woody means neither of those things. It means I want the bleeding edge today, _but_ I want to switch to inhabiting the extremely boring stable-package doldrums starting the day the symlinks change, _and_, later on, I want to switch to using all-unmaintained software starting with the next symlink change after that. I'll continue on sarge for a while (couple of years, I figure) once it goes stable. I hope (with the above background), my rhetorical question about this intention is now clearer: Why would you want to be close to the bleeding edge today, but suddenly switch to antique, ultra-stable software starting the day of sarge release? My point is that you're, in effect, _jumping tracks_ if you do that. Absent some compelling reason, that's probably not in your interest. I hear a lot of people say they want to do it, and can't help thinking it means they're a bit fuzzy on how the maintenance system (and tracks) work. In many cases, it may be because they're not used to using a distribution with an ongoing maintenance regime, designed to eliminate the need to ever reinstall or have system downtime during upgrades to new distro versions. With Debian, you _don't do_ distro-version upgrades. You don't need them: You just keep getting new packages to stay your preferred distance away from the bleeding edge (thus: stable, testing, or unstable). I hope that helps. [1] Many admins will not even notice the changeover. That
Re: [vox-tech] Installing subversion from sid into a sarge box
On Wed, 5 Jan 2005, Rick Moen wrote: [...] After that day, systems that are set to track stable will smoothly transition, the next time the users gets package updates, from woody/3.0 package versions to sarge/3.1 ones.[1] [...] Dear Rick, I've been wondering - when Woody is replaced by Sarge, will those following the stable track have to apt-get dist-upgrade, rather than apt-get upgrade, on release day? Yours, Chris ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] Installing subversion from sid into a sarge box
Quoting Chris Jenks ([EMAIL PROTECTED]): I've been wondering - when Woody is replaced by Sarge, will those following the stable track have to apt-get dist-upgrade, rather than apt-get upgrade, on release day? Er, this will seem lame, but I'm not sure. I personally always do dist-upgrade. The difference between the two is pretty subtle: I vaguely recall that dist-upgrade does more intensive handling of dependencies, and is more likely to implicitly introduce new packages you didn't specifically ask for by name. When I was brand-new to all this, the dist-upgrade treatment struck me as better on balance, and so I've always used it instead of upgrade. By the way, consider doing aptitude upgrade (or aptitude dist-upgrade) rather than using apt-get directly. Joey Hess has made an excellent case for why. See: Aptitude on http://linuxmafia.com/kb/Debian/ ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] Installing subversion from sid into a sarge box
Two corrections to a paragraph that I flubbed: Setting your default branch to woody means neither of those things. ^ I meant to say sarge. It means I want the bleeding edge today ^ to be a few steps back from (Being _at_ the bleeding edge means tracking unstable, not testing.) ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] Installing subversion from sid into a sarge box
On Wed 05 Jan 05, 11:37 AM, Rick Moen [EMAIL PROTECTED] said: Quoting Chris Jenks ([EMAIL PROTECTED]): I've been wondering - when Woody is replaced by Sarge, will those following the stable track have to apt-get dist-upgrade, rather than apt-get upgrade, on release day? Er, this will seem lame, but I'm not sure. I personally always do dist-upgrade. The difference between the two is pretty subtle: I vaguely recall that dist-upgrade does more intensive handling of dependencies, and is more likely to implicitly introduce new packages you didn't specifically ask for by name. When I was brand-new to all this, the dist-upgrade treatment struck me as better on balance, and so I've always used it instead of upgrade. Rick, as I understand it, an upgrade will refuse to upgrade a package if its dependencies aren't already on the system. dist-upgrade upgrades a package, whether the dependencies are already installed/configured/setup or not. (Again, this is my understanding. The man page for apt-get is impressively vague). Real world example: I hope to become a Debian maintainer sometime this century, and am taking over the yadex package. Yadex used to come with a second binary called ybsp, which was required for Yadex. The author of Yadex realized that ybsp was hackish and there was a MUCH better alternative to ybsp, maintained at sourceforge, called bsp. So he removed ybsp from Yadex and tells Yadex users to get bsp because ybsp is no longer being provided. On the Debian side, I packaged the most recent version of Yadex, that no longer comes with ybsp. I also created a brand new package, bsp. Since Yadex *requires* a node builder in order to do anything useful, bsp is listed as a required package for Yadex. A Yadex user on Debian who does: apt-get upgrade will see that the yadex package is on hold because it has a dependency that isn't currently on the system (bsp can't be on the system because it's brand new to Debian). An apt-get install will bring the package plus all its dependencies in. But an upgrade will refuse unless the dependencies are all present. To upgrade yadex, the user has to use: apt-get dist-upgrade and apt-get will first install the new bsp package, and then upgrade the yadex package. At least, this is my understanding. By the way, consider doing aptitude upgrade (or aptitude dist-upgrade) rather than using apt-get directly. Joey Hess has made an excellent case for why. See: Aptitude on http://linuxmafia.com/kb/Debian/ Mon dieu! La mort a apt-get! Vive la aptitude! This should be _required_ reading. I had no idea aptitude was so cool. I used to use it a long time ago, but it was taken out of Debian for awhile and I forgot about it. I even have a favorite quote from that page: If you're a dselect user, learning curve is obviously not one of your problems. Pete -- The mathematics of physics has become ever more abstract, rather than more complicated. The mind of God appears to be abstract but not complicated. He also appears to like group theory. -- Tony Zee's Fearful Symmetry GPG Fingerprint: B9F1 6CF3 47C4 7CD8 D33E 70A9 A3B9 1945 67EA 951D ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] Installing subversion from sid into a sarge box
Rick Moen wrote: Quoting Jay Strauss ([EMAIL PROTECTED]): However, I'm always surprised at people saying they want to be on the testing track prior to release, but not afterwards. Why is that track desirable today, but not after sarge's relese? I just want the newer stuff, Perl primarily. You might want to track testing, then. More below. And since sarge is almost stable seems to be the right dist for me. It's possible that there's a bit of lingering confusion, so please pardon my going didactic (er, more didactic ;- ) on you for a while: The Debian branches named for Toy Story characters (buzz=1.1, rex=1.2, bo=1.3, hamm=2.0, slink=2.1, potato=2.2, woody=3.0, sarge=3.1, and the planned etch branch that isn't yet extant) are _starting points_ -- installable package ensembles -- for Debian systems. Absent special ... Rick, Thanks for the reply. Maybe I'll be better served if I say what I'm trying to accomplish. I (mostly) write Perl against Oracle, with some apache/mod_perl thrown in too. I need the newer version of perl (5.8.4 w/threads), I need the glibc in testing for Oracle (Oracle 10 installs (almost) without hitch on testing, but very difficult, impossible, on stable). I'll install apache2/mod_perl2 also. Lastly I'd like to have subversion 1.1 Currently, the testing branch, has all that I need, with the exception of subversion v1.1 (which is currently in unstable). That said, I'm risk adverse and would like to be on the stable version, for the duration. So I'd like to stay a safe distance from bleeding edge, but have all the above. I thought the debian maintainers, at some point stop accepting changes to testing, say ok, this package set is now stable, and point everything appropriately. What I thought I'd do is run testing until the day(s) that it becomes stable, then make my box follow the stable tree. Jay ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] Installing subversion from sid into a sarge box
On Wed 05 Jan 05, 3:44 PM, Jay Strauss [EMAIL PROTECTED] said: I need the newer version of perl (5.8.4 w/threads), I need the glibc in testing for Oracle (Oracle 10 installs (almost) without hitch on testing, but very difficult, impossible, on stable). I'll install apache2/mod_perl2 also. Lastly I'd like to have subversion 1.1 Currently, the testing branch, has all that I need, with the exception of subversion v1.1 (which is currently in unstable). That said, I'm risk adverse and would like to be on the stable version, for the duration. So I'd like to stay a safe distance from bleeding edge, but have all the above. FWIW, the Linux kernel and the GNU glibc are the two most mission critical things on your system. I thought the debian maintainers, at some point stop accepting changes to testing, say ok, this package set is now stable, and point everything appropriately. That's true. But I believe it's the release manager who gets to make that decision. The developers are probably scrambling to release new packages before the impending package freeze. I *think* you're allowed to petition for a new package to be accepted after the freeze, but you need a good reason like a vulnerability fix. What I thought I'd do is run testing until the day(s) that it becomes stable, then make my box follow the stable tree. If I understand it correctly, you want to point your sources to sarge. When sarge becomes stable, your system will become Debian/stable. Pete -- The mathematics of physics has become ever more abstract, rather than more complicated. The mind of God appears to be abstract but not complicated. He also appears to like group theory. -- Tony Zee's Fearful Symmetry GPG Fingerprint: B9F1 6CF3 47C4 7CD8 D33E 70A9 A3B9 1945 67EA 951D ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] Installing subversion from sid into a sarge box
On Tue, 4 Jan 2005, Jay Strauss wrote:
Hi,
I want to install the 1.1.1-2 version of subversion, onto my stock sarge
box (sarge contains v1.0.9).
After reading the apt manual, I seems like I should be able to add the
unstable tree into my sources.list, add an entry into my
/etc/apt/apt.conf like:
APT::Default-Release testing; # to keep everything at sarge
The comment on that line is wrong... it keeps everything at testing.
When Sarge becomes stable, changes from Sid will be held in check for
awhile, and then when the change occurs you'll suddenly download all the
backed up changes at your next apt-get update, and be off and running in
the wild world of whatever the testing version is that follows Sarge.
I am pretty sure you should be able to use sarge instead of testing if
you want to step off the freight train at that point.
And I'm good to go.
But, I don't have a /etc/apt/apt.conf, there is a
/etc/apt/apt.conf.d/70debconf which contains:
iron:~# cat /etc/apt/apt.conf.d/70debconf
// Pre-configure all packages with debconf before they are installed.
// If you don't like it, comment it out.
DPkg::Pre-Install-Pkgs {/usr/sbin/dpkg-preconfigure --apt || true;};
Am I supposed just create this file myself?
I don't want to hose myself. I've just finally got this machine looking
sorta how I want it :)
I'm just a monkey with a wrench here, but I created a file called
/etc/apt/apt.conf.d/60defaultrelease with contents set to the line you
quoted above this summer, and my system is still working.
---
Jeff NewmillerThe . . Go Live...
DCN:[EMAIL PROTECTED]Basics: ##.#. ##.#. Live Go...
Live: OO#.. Dead: OO#.. Playing
Research Engineer (Solar/BatteriesO.O#. #.O#. with
/Software/Embedded Controllers) .OO#. .OO#. rocks...1k
---
___
vox-tech mailing list
vox-tech@lists.lugod.org
http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] Installing subversion from sid into a sarge box
Quoting Jay Strauss ([EMAIL PROTECTED]):
After reading the apt manual, I seems like I should be able to add the
unstable tree into my sources.list, add an entry into my
/etc/apt/apt.conf like:
APT::Default-Release testing; # to keep everything at sarge
And I'm good to go.
According to man 5 apt_preferences, this is the _correct_ way to solve
the problem. (Me, I'm a lamer and thus quit studying the manpage the
moment I found a NON-standard solution to the problem that works. More
about that near the end.)
But, I don't have a /etc/apt/apt.conf [...]
Am I supposed just create this file myself?
Yep.
I created an /etc/apt/apt.conf file for a completely _unrelated_ reason,
to accomplish this bit of coolness:
:r! /etc/apt/apt.conf
DPkg {
// Auto re-mounting of a readonly /usr
Pre-Install-Pkgs {/home/rick/aptdpkgro.sh;};
Pre-Invoke {mount -o remount,rw /usr;};
Post-Invoke {/home/rick/aptdpkgclean.sh; mount -o remount,ro /usr;};
}
/home/rick/aptdpkgro.sh is:
#!/bin/sh
pathmatch=^/usr
while read debname; do
pkg=$(dpkg --info $debname | sed -n 's/^ Package: *//p' | head -1)
(dpkg -L $pkg 2/dev/null || true) | grep $pathmatch |
while read file; do
[ -f $file -a ! -L $file ] || continue
dir=`dirname $file`;
base=`basename $file`;
inode=`find $file -printf %i\n`
(cd $dir ln $base .${base}.dpkg-ro-used.$inode)
echo $dir/.${base}.dpkg-ro-used.$inode
done /var/lib/my_ro_hack.todel
done
/home/rick/aptdpkgclean.sh is:
#!/bin/sh
pathmatch=^/usr
cat /var/lib/my_ro_hack.todel | while read file; do
[ -f $file ] || continue
N1=`find $file -printf %i\n`
b=`basename $file`; d=`dirname $file`
XF=${b#.}; XF=$d/${XF%.dpkg-ro-used.*}
N2=`find $XF -printf %i\n`
if [ $N1 != $N2 ] ! fuser -s $file; then
rm -f $file
else
echo $file
fi
done /var/lib/my_ro_hack.todel.new
mv /var/lib/my_ro_hack.todel.new /var/lib/my_ro_hack.todel
Anyhow, my lame, slacker, non-orthodox solution to the problem is to NOT
declare a default release in /etc/apt/apt.conf, but instead put these
three lines into /etc/apt/preferences:
Package: *
Pin: release a=unstable
Pin-Priority: 50
Then, /etc/apt/sources.list gets lines for both testing and unstable,
then I do aptitude update[1], et voila. Works for Metm.
The full, very verbose explanation for why that works is apparently in
the apt_preferences manpage, but, being a lazy git, I've never taken the
time to properly read that.
[1] See: Aptitude on http://linuxmafia.com/kb/Debian/
___
vox-tech mailing list
vox-tech@lists.lugod.org
http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] Installing subversion from sid into a sarge box
Quoting Jeff Newmiller ([EMAIL PROTECTED]): APT::Default-Release testing; # to keep everything at sarge The comment on that line is wrong... it keeps everything at testing. When Sarge becomes stable, changes from Sid will be held in check for awhile, and then when the change occurs you'll suddenly download all the backed up changes at your next apt-get update, and be off and running in the wild world of whatever the testing version is that follows Sarge. I am pretty sure you should be able to use sarge instead of testing if you want to step off the freight train at that point. The comment string is indeed inaccurate, and your point is well taken. However, I'm always surprised at people saying they want to be on the testing track prior to release, but not afterwards. Why is that track desirable today, but not after sarge's relese? On the other hand, if he wanted to be on the stable track after release, why would he want to be on a different track (testing) today? Putting sarge in the /etc/apt/apt.conf line as Default-Release, or specifying it in your /etc/apt/sources.list lines, means you're (effectively) telling the system I want to be on the testing track until the exact moment of sarge's release, at which time I want to suddenly jump to Debian's stable track. Moreover, unless I reconfigure you, I want to _stay_ with sarge after etch (3.2) becomes the replacement stable release, and cease getting updates at all after sarge is re-symlinked to old-stable and eventually mothballed to the archives. Just a different perspective. ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
