[svlug] Which linux distro for production ?

Ivan Sergio Borgonovo mail at webthatworks.it
Sat Dec 18 15:40:23 PST 2004


On Sat, 18 Dec 2004 12:16:53 -0800
Rick Moen <rick at linuxmafia.com> wrote:

> Let's please not confuse the open source / proprietary distinction
> with that of lawfully redistributable versus not.  Last I checked,
> _all_ SUSE editions included proprietary ("non-free") software, and
> I'm not just referring to the prior releases of YaST. 

Yep. I tend to be more precise when I'm not tired. I appreciate the
difference, so I'm sorry I may have created some confusion in to
others as well.

> > why? I had a couple of resolvable problems on desktops mainly for
> > stupidity on my part. Otherwise I had a good experience with
> > apt4rpm.

> YaST Online Updater's (YOU's) repositories are probably more
> systematically maintained.  Just a hunch, based on analogous
> situations elsewhere.

SUSE doesn't seem to support anything other than patches. There are
semi-official updates for KDE, Gnome, Apache, samba and maybe a few
more other packages (SUSE merged the site with Novel and I find hard
to look for the semi-official packages). Then there are "less than
semi-supported" SUSE repositories, mainly development versions offered
by SUSE employees. Then there are a bunch of independent developers
that do a pretty good job. If you stick with YOU repositories you'd
get just patches, no new versions.

> :r /etc/apt/preferences
> 
> Package: *
> Pin: release a=unstable
> Pin-Priority: 50

I think this should be enough to let me try.

The rest of the explanation was enlightening too, especially the
reason to "mix" unstable and testing.

I'd suggest you to publish it on your site.

Due to my lack of knowledge about the so strict relationship between
unstable and testing I thought it could be more troublesome to "mix"
them.

> > It seems surely more reasonable to mix unstable and testing rather
> > than testing and stable because testing receives security updates
> > later than sid.

> No, it's more reasonable to "mix unstable and testing" (which is
> inaccurate -- I was actually referring to gaining access to

What did I wrote?

> unstable-branch packages on an otherwise testing-branch system) than
> testing and stable because the package-version gap between testing
> and stable is severe and the results are predictably dysfunctional.
> Attempting the latter "pinning" configuration is a common bonehead
> error.

Exactly, whatever I wrote, whatever you understood that was what I
meant.

> > Stable and sid may be too different to be worth to try
> > to mix without major PITA.

> (You mean stable and unstable.)

Isn't sid the invariant name of unstable?

> > But then why should I bother to have packages from testing at all?

> Maybe, like me, you appreciate the benefits of quarantining.

Yeah, not that is clear, for sure.

> > Furthermore I can't find any completely convincing criteria about
> > which packages should come from testing and which one from
> > unstable.

> I'm not entirely sure you understood how pinning works, when you
> wrote that.  

Now I think enough to follow you.
I think reasonable criteria to pick from unstable could be:
- security
- something not critical I'd like to try

> First, please understand that pinning is much more general mechanism
> for setting package priority than I may have implied.[1]  The
> canonical documentation is in the APT HOWTO, sections 3.8 through
> 3.10:
http://www.debian.org/doc/manuals/apt-howto/ch-apt-get.en.html#s-default-version

I read it before, but your explanation made it much clearer and you
pointed out how it could be used in the case I was interested in.

> > I would consider to chose exposed packages from sid cos they will
> > receive security packages earlier and to take not exposed packages
> > and to take not exposed packages from testing.

> "Receive security packages"?  Huh?  Obviously, you are not correctly
> understanding what is meant by the term "pinning" in this context.
> (A particular package can be pinned to a particular version or range
> of versions, but that's not the way I've used it.)

OK, let's put it in another way. It is better to have unstable too in
sources.list than just testing for security reasons.

> I think I can guess what's wrong:  You probably assumes that one

I didn't assume anything, I had 2 vague ideas: pinning is a system to
let live together 2 releases, it works assigning priorities.


> [1] Also, the method I used, of declaring a low pin-priority for a
> branch I want to be non-default, is unusual.  The standard method is
> to declare a default branch in /etc/apt/apt.conf , using the
> "APT::Default-Release" keyword.  Quoting the apt-preferences(5)
> manpage:
> 
>        APT::Default-Release "stable";

If I interpret right, I can obtain the same effect defining
APT::Default-Release "testing", including in sources.list, testing and
unstable and then using apt -t unstable package as you suggested.

> There is more in there.  You should read the manpage if interested,
> as well as /usr/share/doc/apt/examples/configure-index.gz to see all
> possible configuration options for /etc/apt/apt.conf .

Just turning on my Debian box (that is pretty noisy) to move some docs
to my workstation.
I think I'll try your suggested setup on a spare workstation tomorrow.

As usual you've been very helpful.





More information about the svlug mailing list