Re: alsa-base breaks linux-sound-base
On Mon, 03 Sep 2012 18:20:35 +0200, lee wrote:
> Camaleón <noelamac@gmail.com> writes:
(...)
>>> What's wrong with it? Aptitude installs packages from testing by
>>> default and installs packages from unstable or experimental when I
>>> tell it to, which is what I want.
>>
>> Nothing wrong "per se" but when using such mixed repositories you have
>> to carefully watch for what gets installed/updated, from where it comes
>> and if the update routine is finally doing what you wanted to do. In
>> brief, you have to be very cautious or your system can badly break.
>
> I'm paying attention to that in any case. It's pretty easy, I just look
> at what aptitude would do, and if I don't like it, I don't let it do
> what it wants. I don't override dependencies and only install software
> that isn't in either Debian or Debian-multimedia when it really cannot
> be avoided.
It hasn't to be that easy given that you were not able to update your
system (hope you remember there were 148 packages that wanted to change -
ahem... downgrade- their version >:-) )
> If package maintainers set up dependencies in such a way that stuff
> installs flawlessly and then something breaks, I'll have a problem.
> There probably isn't any good way to prevent that, other than building
> everything from scratch, which would involve to take care of all
> dependencies myself. That would probably be worse.
I dont't think that's the case. Dependencies are established as they
should for every Debian flavor, but as you may know, it's up to the user
having to deal with priorities when the updater routine is doing what you
have instructed to do (if you're in disagreement with the apt proposal
then you will have to manually make your own changes and take your own
decisions on how to proceed -what to keep/what to change).
> And what is worse? Having to wait until a bugfix finally makes it into a
> Debian package that is in stable (or testing) or use a Debian package
> from unstable or, if that cannot be avoided, from experimental --- or
> ignore the package management and get the source and compile and install
> yourself whatever you need?
I think you still don't understand what Debian releases are for: you
simply can't have the four branches (stable/testing/sid/experimental)
enabled by default and wait for the updater do its job "automagically". I
have little experience with mixing the 4 branches but I do know that this
is not going to work unless I put something on my part.
Should I need the most updated versions of the packages I'd go for a pure
Sid installation. Period.
>>>> You need an urgent reorganization for your repos and also reducing
>>>> the number of them as you have too many defined.
>>>
>>> Why?
>>
>> To avoid your system from trying to downgrade a bunch of core packages?
>> ;-)
>
> Aptitude doesn't try that. If I removed unstable and experimental, what
> other choice would there be but to downgrade packages, leaving me with
> some stuff not working since packages from unstable are installed
> *because* there have been bugfixes?
I can't really tell what would be the best option for you with your
current system, it's too messed.
> Maybe I don't understand the problem, so let's take the mumble server
> for an example:
(...)
Okay, but not here, you better open a new thread, please.
>>> If I was to remove unstable and experimental, how would I install
>>> packages from these when needed?
>>
>> You can't but then you have to know how proceed under this scenario. I
>> mean, having a complete mix of stable/testing/unstable/experimental and
>> external repositories is not for beginners: you have to understand in
>> deep how this works.
>
> Well, I haven't installed packages from stable.
(...)
That's irrelevant for the matter. The problem was there were hundred
packages that were marked to be downgraded... you have to deal with/solve
that.
> Having some packages from unstable installed along with the ones from
> testing is a situation that will "fix" itself over time when more recent
> versions of these packages make it into testing, replacing the ones from
> unstable.
Or not... remember that the testing branch is not a "true" rolling
distribution like Sid is (testing is now "frozen" and is not going to
receive many upgrades).
> In the meantime, I have a working system without having to worry about
> keeping track of self-installed software and dependency problems that
> might arise from it. Just don't circumvent the package management --- I
> tried that many years ago and found out it's a very bad idea, so I
> don't do that.
So now what? How are you dealing with your apt problem?
>>> And if I removed Debian multimedia, I would miss a lot of packages.
>>
>> Sure, such is life :-)
>>
>> Or you can also "cherry pick" some packages from d-m and then turn off
>> this repository from your sources.list.
>
> And turn it back on every time I check for updates?
Yes, that way you'll never take a bad step.
> Or skip the updates and only turn it back on when dependency problems
> come up because the cherry-picked packages have become too old?
This shouldn't be a problem for d-m packages.
>>> Perhaps I don't need the security updates because there aren't any for
>>> testing, but they don't seem to hurt anything.
>>
>> Security updates is one of the repos I would leave. But I'm afraid I
>> have a completely point of view than yours about how to use a system, I
>> mean, I prefer stability over new features and you seem to look for the
>> opposite. Anyway, if that's your case, I would simply install "sid" and
>> problem solved :-)
>
> Nope, reliability is much more important to me than new features.
That makes not sense for someone using packages from experimental ;-)
> It's not about new features, it's about having what you need. If I was
> running stable, I won't install exim4 from testing or unstable because
> it has five or ten new features I don't need or a fix for two bugs that
> never occur in my application. When I need the features, I start
> thinking about it. When the bugs occur in my application and I need the
> fix, I'm likely to install the version from testing/unstable to get
> things working. When my X-session randomly freezes and I suspect it's
> due to NVIDIA drivers, I'm looking for more recent ones and try them
> because the problem might be fixed already.
The theory is right but practise differs because most of the time going
that way will need that you install core packages from testing/unstable
branch and your problems will start from here.
> Besides, look at the NVIDIA drivers in stable: They are ancient.
(...)
(no sorry, not in this thread)
> Reliability is actually the reason why I'm running testing instead of
> stable: When you run stable, you have to make relatively big leaps when
> you upgrade from one stable release to the next. You don't need that
> with testing as the leaps are relatively small and don't happen all at
> once and thus are much easier to handle. It's trading one risk for
> another.
You have a particular way of how your system has to be which completely
differs from mine but let's keep this on-topic :-)
>>> Well, what do you do when your X-session randomly freezes?
>>
>> Report it? What is for sure is that I'm not going to sacrifice my whole
>> system stability for a VGA problem.
>
> There wasn't anything useful to report because the only thing I could do
> was pressing the reset button. The freeze might not occur for two days
> and might occur twice within an hour or only once a day. It wasn't
> reproducible, and since I had to press reset, there wasn't any
> information I could have provided. I have no way of telling what caused
> the problem, it might have been something else than the NVIDIA drivers.
You only have to report what it happens and wait for a reply, no more no
less, reporters do not have to know how to deal with a problem but tell
the people in the know what's going on (reporters are neither software
developers nor packagers).
> I haven't sacrificed the stability of the whole system by trying out
> more recent NVIDIA drivers.
(...)
There are more ways for going so. There are also a different set of
drivers you can use. There are alternatives and YOU selected one of the
ways to go.
>>> When using the packet management means high cost, what else do you
>>> suggest to use?
>>
>> Using the package manager is not the problem here. The problem is
>> mixing "all" Debian flavours and think this is going to magically work
>> with no additional tweaks ;-)
>
> It's working fine, so I'm not worrying about it. If there are packages
> in testing that don't work together with packages from unstable, I
> expect the packet management to tell me this, and so far it does so
> nicely. Do you have an example for a tweak that would be required to
> make?
Nothing you'll like hearing about, I guess. Given the current status of
your system I would start completely from scratch and stick to just one
branch.
Greetings,
--
Camaleón
Reply to: