Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #178031 > unrolled thread

Using source packages to bring some programs up to latest version

Back to article view | Back to linux.debian.user

Contents

  Using source packages to bring some programs up to latest version David Niklas <doark@mail.com> - 2017-02-20 22:30 +0100
    Re: Using source packages to bring some programs up to latest version Jonathan Dowland <jmtd@debian.org> - 2017-02-21 00:00 +0100
      Re: Using source packages to bring some programs up to latest version Greg Wooledge <wooledg@eeg.ccf.org> - 2017-02-21 14:00 +0100
        Re: Using source packages to bring some programs up to latest version Jonathan Dowland <jmtd@debian.org> - 2017-02-22 10:00 +0100
          Re: Using source packages to bring some programs up to latest version Mark Fletcher <mark27q1@gmail.com> - 2017-02-22 15:20 +0100
            Re: Using source packages to bring some programs up to latest version Jonathan Dowland <jmtd@debian.org> - 2017-02-23 15:30 +0100

#178031 — Using source packages to bring some programs up to latest version

Hello,
I've used Debian on and off but now I have a pocketchip from
https://nextthing.co/
and it uses debian and I'm not about to switch.
I follow several projects closely (nano, lynx, a few others), and what I
want to do is to tell apt to:
1. Download the latest and greatest source code of version of package X
2. Resolve all dependencies of package X downloading source code
3. Resolve packages that depend on X and download source code
4. Compile sources and install X and dependencies.

I realize that several of theses steps may make up one actual command and
visa-versa.
What I'm trying to do is to avoid running pieces unstable or testing
software (except for the package I asked for (such as nano)), while
still having a few newer packages.

Thanks,
David

[toc] | [next] | [standalone]

#178034

[Multipart message — attachments visible in raw view] — view raw

On Mon, Feb 20, 2017 at 04:07:48PM -0500, David Niklas wrote:
> What I'm trying to do is to avoid running pieces unstable or testing
> software (except for the package I asked for (such as nano)), while
> still having a few newer packages.

The best way to achieve this is to use backports, if one exists for the
packages you are interested in.

Failing that, it's possible that the version of the package in testing or
unstable can be installed on your stable system without pulling in any (or too
many) dependencies from outside stable. You need to add testing (and/or
unstable) sources to Apt's sources.list *and* set up pinning so that Apt always
prefers packages from stable over anything else. Then, you can do something
like
	apt-get install -t testing somepackage
or
	apt-get install somepackage=desired-version

Inspect the list of packages that it wants to pull in, and their versions
(if you see that in the apt pre-run output, I can't remember) and make a
judgement call as to whether you're happy to install them.

Finally, if the above isn't satisfactory, you can attempt to build the newer
version from source. (I will leave details of that to another email)


-- 
Jonathan Dowland
Please do not CC me, I am subscribed to the list.

[toc] | [prev] | [next] | [standalone]

#178043

On Mon, Feb 20, 2017 at 10:52:37PM +0000, Jonathan Dowland wrote:
> The best way to achieve this is to use backports, if one exists for the
> packages you are interested in.
> 
> Failing that, it's possible that the version of the package in testing or
> unstable can be installed on your stable system without pulling in any (or too
> many) dependencies from outside stable.

No, stop.  The second step if there is not already a backport is to try
to backport it yourself.  Maybe ask judd in IRC first, whether a backport
is believed to be *possible*.  Sometimes the bot is wrong, but it's a
starting point.  If judd thinks all the dependencies are satisfiable,
then you can try the backport.

If a backport isn't possible, I would actually prefer to build the package
normally from upstream source code (./configure; make; sudo make install)
than to install a binary from testing/unstable onto stable.

[toc] | [prev] | [next] | [standalone]

#178061

[Multipart message — attachments visible in raw view] — view raw

On Tue, Feb 21, 2017 at 07:51:20AM -0500, Greg Wooledge wrote:
> No, stop.  The second step if there is not already a backport is to try
> to backport it yourself.  Maybe ask judd in IRC first, whether a backport
> is believed to be *possible*.  Sometimes the bot is wrong, but it's a
> starting point.  If judd thinks all the dependencies are satisfiable,
> then you can try the backport.

judd sounds like a useful system, but I disagree that the next step is
necessarily backports.  For example, I just recently installed sid's "flatpak"
on a stretch system, and all dependencies were satisfyable from stretch (in
fact, were already installed, from when I installed the version of flatpak in
stretch). So sometimes this is a quick solution.

If the version in sid had wanted to pull in dependencies from sid, then I would
have had to make a judgement call as to the impact of that, versus the
inconvenience of building from source.

> If a backport isn't possible, I would actually prefer to build the package
> normally from upstream source code (./configure; make; sudo make install)
> than to install a binary from testing/unstable onto stable.

Yes, I think that might actually be easier than wrangling with Debian
packaging, especially if the user is not already familiar with it.

-- 
Jonathan Dowland
Please do not CC me, I am subscribed to the list.

[toc] | [prev] | [next] | [standalone]

#178066

On Wed, Feb 22, 2017 at 08:51:10AM +0000, Jonathan Dowland wrote:
> On Tue, Feb 21, 2017 at 07:51:20AM -0500, Greg Wooledge wrote:
> > No, stop.  The second step if there is not already a backport is to try
> > to backport it yourself.  Maybe ask judd in IRC first, whether a backport
> > is believed to be *possible*.  Sometimes the bot is wrong, but it's a
> > starting point.  If judd thinks all the dependencies are satisfiable,
> > then you can try the backport.
> 
> judd sounds like a useful system, but I disagree that the next step is
> necessarily backports.  For example, I just recently installed sid's "flatpak"
> on a stretch system, and all dependencies were satisfyable from stretch (in
> fact, were already installed, from when I installed the version of flatpak in
> stretch). So sometimes this is a quick solution.
> 
> If the version in sid had wanted to pull in dependencies from sid, then I would
> have had to make a judgement call as to the impact of that, versus the
> inconvenience of building from source.
> 
> > If a backport isn't possible, I would actually prefer to build the package
> > normally from upstream source code (./configure; make; sudo make install)
> > than to install a binary from testing/unstable onto stable.
> 
> Yes, I think that might actually be easier than wrangling with Debian
> packaging, especially if the user is not already familiar with it.
> 

The only thing I'd add here is that in this case, I'd create a dummy 
Debian package with no contents but an appropriate version number and 
dependencies, and install it, so the system knows it is there and the 
dependent libraries are depended on. This way when upgrades happen APT 
will tell you if there is going to be a problem upgrading the libraries 
instead of just doing it and breaking the package you built from source.

Mark

[toc] | [prev] | [next] | [standalone]

#178105

[Multipart message — attachments visible in raw view] — view raw

On Wed, Feb 22, 2017 at 11:11:27PM +0900, Mark Fletcher wrote:
> The only thing I'd add here is that in this case, I'd create a dummy 
> Debian package with no contents but an appropriate version number and 
> dependencies, and install it, so the system knows it is there and the 
> dependent libraries are depended on. This way when upgrades happen APT 
> will tell you if there is going to be a problem upgrading the libraries 
> instead of just doing it and breaking the package you built from source.

Not a bad idea. You can use equivs to achieve this (although equivs could
do with a rewrite IMHO)

-- 
Jonathan Dowland
Please do not CC me, I am subscribed to the list.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web