installing a testing package emacs25 corrupts at totally

[debiman]

And the poetry (trolling?) lies in the freestyle discussions. For example, you say that you don't understand the thread and ask questions for which you probably already know the answer. It is poetic because you don't control yourself when loading discussions with feelings.

so by op's own admission this thread is and has always been totally pointless, from a linux point of view.
fine with me.

[MagicPoulp]

Not at all.

1. In testing, one has access to more packages and more versions.

He is one example unixodbc. Present in testing but not in stable. When a package is present in stable, one can sometimes have a more recent version in testing.

2. That apt or aptitude can get broken and hard to recover, present with the same error in another post.

[bw123]

Not at all.

1. In testing, one has access to more packages and more versions.

He is one example unixodbc. Present in testing but not in stable. When a package is present in stable, one can sometimes have a more recent version in testing.

2. That apt or aptitude can get broken and hard to recover, present with the same error in another post.

It doesn't matter if the more recent pkg is available if it doesn't work. You have access to zillions of pkgs from all over the linux world, but they don't all work on stable. It's an old argument you're making, "I mixed repos before and it worked, now it doesn't so something is wrong."

That's like saying you always got away with cheating at cards, so you don't understand why it's a big deal now...

Feelings and poetry aside, it's a repeat thread of "I broke it by mixing repos." They told you that on the first few replies.

[stevepusser]

There are also well-known methods for getting newer versions of programs on stable that won't break your install...but you've already been pointed to the reading you need to do.

[MagicPoulp]

It doesn't matter if the more recent pkg is available if it doesn't work. You have access to zillions of pkgs from all over the linux world, but they don't all work on stable. It's an old argument you're making, "I mixed repos before and it worked, now it doesn't so something is wrong."

you were answering to this statement: "1. In testing, one has access to more packages and more versions."

No! I persist and sign. I have used many packages from testing. And the cases causing corruption are rare and I can be prepared for corruption using VMs or docker.

Installing ruby-all and ruby-all-dev on testing works very well. And you get more choice of versions than what the stable branch offers.

Concerning the other methods, the backports seem to have much fewer packages than testing. Besides, backports seem to have more dependencies to each other.

Actually, many people would do a better usage of installing the entire debian testing instead of debian stable.

[debiman]

No! I persist and sign. I have used many packages from testing. And the cases causing corruption are rare and I can be prepared for corruption using VMs or docker.

this is a totally different paradigm.
of course, if you break your vm you can always nuke it, and no recommendation about system stability will have any relevance to you.
you are totally entitled to do things that way, and to be fair, you mentioned that straight away in your first post, but still i look down on you, and fart in your general direction. now go away or i shall taunt you a second time.

[MagicPoulp]

Mixing stable and testing is not supported and is not recommended. If what you do is programming, it is great to to mix stable and testing to have access to more or newer packages. Since the hardware can fail, it is anyways a good practice to have a system that can be reinstalled without troubles and with backed-up data.

I would not mix stable and testing on a production system though. I would use debian testing.

On many Linux distributions, people are used to install from a manually installed file. It think it is nicer to use an official repository such as debian testing.

Why I am not using debian testing directly instead of mixing stable and testing? I got the "feeling" stable is better. By mixing, I can control which packages from testing I want.

[Head_on_a_Stick]

On many Linux distributions, people are used to install from a manually installed file. It think it is nicer to use an official repository such as debian testing.

No.

The correct solution is to package up the software locally:

http://forums.debian.net/viewtopic.php?f=16&t=38976

http://forums.debian.net/viewtopic.php?f=16&t=130057

[MagicPoulp]

The correct solution is to package up the software locally:

It seems to me that the source package and the pre-built package have the same dependencies.

--> Why would building from source achieve more stability than using the pre-built package?

Correct solution or not, from a practical point of view, installing pre-built packages when it works is fine when we assume one knows it is not recommended or supported to mix repositories. The guys here saw red hearing about mixing branches because they are used to stabilize servers. I am thinking about the desktop experience for which having newer and more packages is nice.

--> Isn't the most supported and recommended solution to install debian testing itself? What are the inconvenients? It may be testing takes more place and is more unstable than a debian stable with a small package from testing that has very few dependencies. Installing the latest ruby-all and ruby-all-dev seems to be quite inoffensive.

[Head_on_a_Stick]

The correct solution is to package up the software locally:

It seems to me that the source package and the pre-built package have the same dependencies.

No.

As an example, if the package you are installing from testing depends on the version of libc6 from testing then that will break your system.

Building the package in a stable base ensures that only dependencies from stable are needed.

Please read the links I provided, they explain things very well.

--> Isn't the most supported and recommended solution to install debian testing itself? What are the inconvenients?

See this section from the debian-user mailing list FAQ:

https://wiki.debian.org/FAQsFromDebianU ... Testing.3F

[MagicPoulp]

The package one builds from source could require a security update. One will have to track those. The backports have a mailing list. But if one builds a source package, it is not simple to track the security updates. When mixing stable and testing, one can get the security fixes via apt-get dist-upgrade without having to track anything. But I totally agree that it is dangerous since stable and testing should not be mixed and if one does there is a huge risk of breaking stability.

I am not completely sure, but I don't think there is a repository for backports security updates.

testing has this source repo:
deb http://deb.debian.org/debian-security testing/updates main

[None1975]

I am not completely sure, but I don't think there is a repository for backports security updates.

According Debian Backports FAQ:

Q: Is there security support for packages from backports.debian.org?
A: Unfortunately not. This is done on a best effort basis by the people who track the package, usually the ones who originally did upload the package into backports. When security related bugs are fixed in Debian unstable the backporter is permitted to upload the package from directly there instead of having to wait until the fix hits testing. You can see the open issues for jessie-backports in the security tracker (though there may be false positives too, the version compare isn't perfect yet)

[sunrat]

testing has this source repo:
deb http://deb.debian.org/debian-security testing/updates main

You will not find any packages in there. I think it's just set up so there's a place for updates when buster becomes stable.

[Head_on_a_Stick]

if one builds a source package, it is not simple to track the security updates.

Follow the upstream github page, perhaps? That's what I do

[MagicPoulp]

testing has this source repo:
deb http://deb.debian.org/debian-security testing/updates main

You will not find any packages in there. I think it's just set up so there's a place for updates when buster becomes stable.

Anyways, security updates will be present in the main repository.

I found in the documentation that debian testing is lagging in security updates behind unstable, and that only stable can be relied on for security. Besides, even if testing has security updates that backports don't have, it does not give a guarantee. And mailing lists with backports may be more reliable than updates that are planned in testing.

https://www.debian.org/security/faq#testing

That gives me one more reason for not installing the total debian testing or debian unstable, and prefering a franken-debian mix. Because stable has more guarantee for stability and security updates.

[MagicPoulp]

if one builds a source package, it is not simple to track the security updates.

Follow the upstream github page, perhaps? That's what I do

I don't know since I almost never used backports. But it seems to me that backports work with mailing lists one registers to for bugs and alerts, and those lists are managed in a best effort by the creator of the backport. My point is that with using testing/unstable one can forget about it and get the updates via apt-get.

In summary, using backports is mentioned in the official way of mixing stable with newer packages because it maintains stability. But using unstable directly might be more secure and more up-to-date. But yes it can break the system or what I call "the installation". Usually it does not break with 1 or 2 packages installed including dependencies. One can control what one installs. When I mentionned in the post opening the package emacs-goodies-el that broke my ssytem, there was 500MB with as many as 40 packages that were installed.

People don't like the idea of having an install that can break any time. It is fine. One just needs to back up precious data or to run experiments in a virtual machine.

[Head_on_a_Stick]

[it seems to me that backports work with mailing lists one registers to for bugs and alerts

No, backports are drawn from testing, usually quite quickly but it varies. This means they get delayed updates from upstream.

[debiman]

That gives me one more reason for not installing the total debian testing or debian unstable, and prefering a franken-debian mix. Because stable has more guarantee for stability and security updates.

i will hold you to that when you start posting desperate help requests.

[MagicPoulp]

That gives me one more reason for not installing the total debian testing or debian unstable, and prefering a franken-debian mix. Because stable has more guarantee for stability and security updates.

i will hold you to that when you start posting desperate help requests.

You need to think in a more concrete way. There are actual facts that make a scenario useful.
1 - Debian stable with one extra package from testing (ruby-all)
2 - debian testing
3 - debian unstable

And the scenario 1 is obviously more stable and with security support than the others. But this is not true in general. No need to be ironic because in general it is wrong to mix.