managing source packages
 

Hi,

I have been using Debian stable on my laptop for some time now, and I
really appreciate it, especially because updates do not break things
that work well. However, sometimes I need a package/feature that is only
in testing/unstable, and which is not (yet) in backports. The safest way
(I guess) to deal with those packages is to install them from source
using "apt-get build-dep / apt-get -b source / dpkg -i", but there are
several shortcomings of this method, which I describe below. Any
thoughts of how one can manage source packages better would be appreciated.

1. Installing/building dependencies

Say, I want to build a package pkg1. Usually, "apt-get build-dep pkg1"
will install all dependencies. However, apt-get will fail if one of
them, say pkg2, is not in "stable". Then, I have to install dependencies
of pkg2, build pkg2 itself, and possibly do so recursively with
dependencies of pkg2 (and it took me hours when I tried that with
texlive...). It would be nice if "apt-get" (or some other tool) would
just try to resolve that itself, e.g., write "I need to install packages
pkgA, pkgB from Etch, and build+install source packages pkgTestingA,
pkgTestingB from Lenny. Do you want to continue? [Y/N]".

2. Keeping packages up to date

Is there any way of automatic updating of packages built from source
"debs"? It would be nice to have something like "apt-get source-update".

3. Removing (build) dependencies

Say, I installed a package pkg1 from source "debs". I needed to install
pkg2 as a dependency of pkg1, and pkg3 as a build-time dependency of
pkg1. Is there any way to remove pkg2 and pkg3 when pkg1 is,
respectively, removed or built?

I have heard that "aptitude" might have some of those features in the
future, and I can try to write scripts that solve the problem. But if
there already is a viable solution, I will not "reinvent the wheel".

Best,

Michal


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

managing source packages
 

On Wed, Jun 04, 2008 at 04:18:11PM +0200, Michal Kapalka wrote:
> I have been using Debian stable on my laptop for some time now, and I
> really appreciate it, especially because updates do not break things
> that work well. However, sometimes I need a package/feature that is only
> in testing/unstable, and which is not (yet) in backports. The safest way
> (I guess) to deal with those packages is to install them from source
> using "apt-get build-dep / apt-get -b source / dpkg -i", but there are
> several shortcomings of this method, which I describe below. Any
> thoughts of how one can manage source packages better would be appreciated.
>
> 1. Installing/building dependencies
>
> Say, I want to build a package pkg1. Usually, "apt-get build-dep pkg1"
> will install all dependencies. However, apt-get will fail if one of
> them, say pkg2, is not in "stable". Then, I have to install dependencies
> of pkg2, build pkg2 itself, and possibly do so recursively with
> dependencies of pkg2 (and it took me hours when I tried that with
> texlive...). It would be nice if "apt-get" (or some other tool) would
> just try to resolve that itself, e.g., write "I need to install packages
> pkgA, pkgB from Etch, and build+install source packages pkgTestingA,
> pkgTestingB from Lenny. Do you want to continue? [Y/N]".

One problem may be that you end up with a mixed system and could break
things. Since disk space is so cheap, why not set up a testing (or Sid)
chroot and install the new stuff there? Access it with schroot.

Doug.


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

managing source packages
 

Hi Michal,

Am 2008-06-04 16:18:11, schrieb Michal Kapalka:
> 1. Installing/building dependencies
>
> Say, I want to build a package pkg1. Usually, "apt-get build-dep pkg1"
> will install all dependencies. However, apt-get will fail if one of
> them, say pkg2, is not in "stable". Then, I have to install dependencies
> of pkg2, build pkg2 itself, and possibly do so recursively with

You have not to

> dependencies of pkg2 (and it took me hours when I tried that with
> texlive...). It would be nice if "apt-get" (or some other tool) would
> just try to resolve that itself, e.g., write "I need to install packages
> pkgA, pkgB from Etch, and build+install source packages pkgTestingA,
> pkgTestingB from Lenny. Do you want to continue? [Y/N]".

The right thing is to

apt-get source <package>
${EDIT} ./package*.dsc

-> downgrade builddepends

${EDIT} package-X-Y-Z/debian/control

-> correct Depends:

cd package-X-Y-Z/

dpkg-buildpackage -rfakeroot

> 2. Keeping packages up to date
>
> Is there any way of automatic updating of packages built from source
> "debs"? It would be nice to have something like "apt-get source-update".

No, you should code a script which do autobuilding with:

1) subscribing to <debian-devel-change@l.d.o>
2) create a package list of your interests
3) if an appropriated message comes in, let the script download it
automaticaly
4) build it in a pure Stable-pbuilder
5) If errors occure inform ${YOU}
a) If there is an error, create a controllscript which solve the
problems by editing the dsc and debian/control files before
building and it will be called the next time the autobuilder
run
b) If there was an error, reinject the message of the failed
package to let it build again...

6) push the package into a local debian-miror and run dpkg-ftparchive

Now you can use

deb http://localhost/debian-backports stable main
and
apt-get update
apt-get install <package>

> 3. Removing (build) dependencies
>
> Say, I installed a package pkg1 from source "debs". I needed to install
> pkg2 as a dependency of pkg1, and pkg3 as a build-time dependency of
> pkg1. Is there any way to remove pkg2 and pkg3 when pkg1 is,
> respectively, removed or built?

Do not do this. Downgrade the Builddepencies versions carefuly.
If thre are NEW packages which do not exist in Stable, try to remove it
and IF it compiles, try the program, if you get errors, PRE-Build this
package and install it.

> I have heard that "aptitude" might have some of those features in the
> future, and I can try to write scripts that solve the problem. But if
> there already is a viable solution, I will not "reinvent the wheel".

I am running "tdautobuilder" but currently I can only say: "It works for
me." I am working on it since it is more complicate as it seems.

Thanks, Greetings and nice Day
Michelle Konzack
Systemadministrator
24V Electronic Engineer
Tamay Dogan Network
Debian GNU/Linux Consultant


--
Linux-User #280138 with the Linux Counter, http://counter.li.org/
##################### Debian GNU/Linux Consultant #####################
Michelle Konzack Apt. 917 ICQ #328449886
+49/177/9351947 50, rue de Soultz MSN LinuxMichi
+33/6/61925193 67100 Strasbourg/France IRC #Debian (irc.icq.com)

managing source packages
 

On Wed, Jun 4, 2008 at 4:18 PM, Michal Kapalka <michal.kapalka@epfl.ch> wrote:
> Hi,
>
> I have been using Debian stable on my laptop for some time now, and I
> really appreciate it, especially because updates do not break things
> that work well. However, sometimes I need a package/feature that is only
> in testing/unstable, and which is not (yet) in backports. The safest way
> (I guess) to deal with those packages is to install them from source
> using "apt-get build-dep / apt-get -b source / dpkg -i"

Most of the time you can install updated debs from unstable or testing
onto stable boxes. Is there a specific reason you can't/won't do this?

Other options:

- Install newer versions from Ubuntu or other 3rd-party locations

- Maintain your own (partial) debian mirror with updated binary
versions for Etch

- Help backports keep your favourite packages up to date.

[...]

> It would be nice if "apt-get" (or some other tool) would
> just try to resolve that itself, e.g., write "I need to install packages
> pkgA, pkgB from Etch, and build+install source packages pkgTestingA,
> pkgTestingB from Lenny. Do you want to continue? [Y/N]".
>

You could try using apt-src or apt-build.

> 3. Removing (build) dependencies
>
> Say, I installed a package pkg1 from source "debs". I needed to install
> pkg2 as a dependency of pkg1, and pkg3 as a build-time dependency of
> pkg1. Is there any way to remove pkg2 and pkg3 when pkg1 is,
> respectively, removed or built?

I use debfoster.

David.


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

managing source packages
 

>> 1. Installing/building dependencies
>>
>> Say, I want to build a package pkg1. Usually, "apt-get build-dep pkg1"
>> will install all dependencies. However, apt-get will fail if one of
>> them, say pkg2, is not in "stable". Then, I have to install dependencies
>> of pkg2, build pkg2 itself, and possibly do so recursively with
>> dependencies of pkg2 (and it took me hours when I tried that with
>> texlive...). It would be nice if "apt-get" (or some other tool) would
>> just try to resolve that itself, e.g., write "I need to install packages
>> pkgA, pkgB from Etch, and build+install source packages pkgTestingA,
>> pkgTestingB from Lenny. Do you want to continue? [Y/N]".
>
> One problem may be that you end up with a mixed system and could break
> things. Since disk space is so cheap, why not set up a testing (or Sid)
> chroot and install the new stuff there? Access it with schroot.

One one hand, schroot is indeed a good idea in the long term, and I
might try it at some point (it also seems like a good alternative to
running Lenny in a VM) -- thanks a lot for the suggestion.

On the other hand, I use source debs only for some individual apps that
do not depend on new versions of important libraries (glibc, gtk, etc.)
so (1) the chance of breaking anything is rather low, and (2) the
solution is very convenient and integrates well with all the other
components of the system. The only problem so far was to manage the
source packages in a convenient way.

Best,

Michal


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

managing source packages
 

>> I have been using Debian stable on my laptop for some time now, and I
>> really appreciate it, especially because updates do not break things
>> that work well. However, sometimes I need a package/feature that is only
>> in testing/unstable, and which is not (yet) in backports. The safest way
>> (I guess) to deal with those packages is to install them from source
>> using "apt-get build-dep / apt-get -b source / dpkg -i"
>
> Most of the time you can install updated debs from unstable or testing
> onto stable boxes. Is there a specific reason you can't/won't do this?

Isn't it less safe than source debs? I mean, those packages are compiled
with newer versions of system libraries than the ones in Etch, so they
may simply refuse to work. The source packages should be safer here --
once they compile on Etch, they should work on Etch without problems.

> Other options:
>
> - Install newer versions from Ubuntu or other 3rd-party locations
>
> - Maintain your own (partial) debian mirror with updated binary
> versions for Etch
>
> - Help backports keep your favourite packages up to date.

Those are indeed good alternatives -- to consider in the future (along
with schroot proposed before).

> You could try using apt-src or apt-build.

This is, more or less, what I was looking for -- I'm not sure if they
have all the features I want, but I see from the man pages that they
should make dealing with source "debs" much easier. Thanks a lot!

> I use debfoster.

>From the home page of debfoster: it has been depreciated, because all
the features of debfoster are already in aptitude.

Best,

Michal


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

managing source packages
 

Michal Kapalka writes:
> Isn't it less safe than source debs? I mean, those packages are compiled
> with newer versions of system libraries than the ones in Etch, so they
> may simply refuse to work.

Libraries have versions. If packages need newer libraries they should
depend on them. If it installs without forcing it should work.
--
John Hasler


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

managing source packages
 

Michal Kapalka wrote:

> Hi,
>
> I have been using Debian stable on my laptop for some time now, and I
> really appreciate it, especially because updates do not break things
> that work well. However, sometimes I need a package/feature that is only
> in testing/unstable, and which is not (yet) in backports. The safest way
> (I guess) to deal with those packages is to install them from source
> using "apt-get build-dep / apt-get -b source / dpkg -i", but there are
> several shortcomings of this method, which I describe below. Any
> thoughts of how one can manage source packages better would be
> appreciated.
>
> 1. Installing/building dependencies
>
> 2. Keeping packages up to date
>
> 3. Removing (build) dependencies
>

Can't you just set up a local repository for the packages that you build and
give them a version number that is between stable and backports? So the
version numbers look like

stable version number --> your custom version number --> backports version
number --> testing version number --> unstable version number.

That way when you upgrade to later versions, it becomes a simple apt-get
task.

hth
raju
--
Kamaraju S Kusumanchi
http://www.people.cornell.edu/pages/kk288/
http://malayamaarutham.blogspot.com/


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

managing source packages
 

On Thu, Jun 5, 2008 at 9:56 AM, Michal Kapalka <michal.kapalka@epfl.ch> wrote:
> >From the home page of debfoster: it has been depreciated, because all
> the features of debfoster are already in aptitude.

The original homepage has this message, but debfoster is still
actively maintained by Debian Developers.

See this page:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=366518

Also see the debian changelog here:

http://packages.debian.org/changelogs/pool/main/d/debfoster/debfoster_2.7-1/changelog

David.


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org