Compilation Question
I have rebuilt kdelibs on Trisquel, incorporating one of the Parabola patches. Once I installed the newly compiled packages, Apper notifies me an 'update' is required, with said update wanting to replace the exact two freshly compiled packages I had just installed. How can I install custom compiled packages on Trisquel in way that Packagekit won't immediately demand my custom compiled packages be replaced? Would I need to increment the package version number in Debian/Rules to resolve it?
> I have rebuilt kdelibs on Trisquel, incorporating one of the
> Parabola
> patches. Once I installed the newly compiled packages, Apper
> notifies
> me an 'update' is required, with said update wanting to replace the
> exact two freshly compiled packages I had just installed. How can I
> install custom compiled packages on Trisquel in way that Packagekit
> won't immediately demand my custom compiled packages be replaced?
> Would I need to increment the package version number in Debian/Rules
> to resolve it?
You'll find the full answer in package maint-guide, it says admin and
install tools use the info in debian/control. You might find it
easier just to code a Trisquel package helper to apply the patch as
they handle all this easily and almost automagically, see
http://trisquel.info/en/wiki/package-helpers . Especially if the
Parabola patch would be of use to Trisquel, as then you could be
extra helpful to everybody else and put the git patch for the package
helper & Parabola patch on trisquel-devel and it might get included
in Trisquel itself.
Leny / Andrew
DNS has already written helpers to free KDE Parabola-style, which is a good thing, because I really don't know what I am doing as far as helpers and lack that kind of skill.
Thanks so much for the tip. I'll poke my nose in the Debian docs and see what I can learn about debian/control.
> DNS has already written helpers to free KDE Parabola-style, which
> is a
> good thing, because I really don't know what I am doing as far as
> helpers and lack that kind of skill.
>
> Thanks so much for the tip. I'll poke my nose in the Debian docs and
> see what I can learn about debian/control.
Digging around to find the answer for myself I see that one
increments the revision of a package with a dch -i .
However, I also realised I answered your question, not your problem.
You could just as easily stop kdelibs being updated by pressing = for
hold against the package name in the aptitude ui.
I don't really want to pin the package on hold. I want to be able to receive any Trisquel updates after I have installed the custom packages, since I can always rebuild it down the road. And since the helpers have already been integrated, it could be the next kdelibs pushed out to us will have the patches already applied.
I still want to know how to do this though, because the end game, if I can get it right, would be to recompile Trisquel on the quad-core, native to atom processors, to install on the netbook. Playing with kdelibs is just a way to (hopefully) get the method down.
> I still want to know how to do this though, because the end game,
> if I
> can get it right, would be to recompile Trisquel on the quad-core,
> native to atom processors to install on the netbook. Playing with
> kdelibs is just a way to (hopefully) get the method down.
Oh, a distinctly non-trivial exercise. Yes, then maint-guide and the
reading it recommends is the best answer I know. But, you might try
PMing jxself (or maybe he'll chip in here) to ask him if he knows a
better way to learn .deb packaging - I just tinker, he maintains that
linux-libre repo. You might also try Francesco Mateotti on the
trisquel-devel mailing list (he last posted in April) to see what he
has learnt about the Trisquel makeiso process in the git when you get
to the point of considering an install disk.
Leny
Ok, here's what I've found. In Trisquel, the two packages Apper/Packagekit wish to update are kdelibs5-data & kdelibs5-plugins, which are the two packages I installed from the compilation. Each of those app names have subfolders in the KDE directory, which has the control file. Here's the control file for kdelibs5-data, with the entries I believe need to be changed:
Breaks: kdelibs5-data (<< 4:4.4.60)
Replaces: kdelibs5-data (<< 4:4.4.60)
If I replace the '4.6.0' entries above with 4.8.5, that should(?) keep the package installed instead of updated away?
Or, would it be better to change the version in the control file, which shows as:
Version: 4:4.8.5-0ubuntu0.1
I could change it to 4.8.5-1ubuntu0.1 or perhaps 4.8.5-0ubuntu0.2
In Parabola, the package name itself is changed, so kdelibs becomes kdelibs-libre, which I greatly prefer. However, the ARCH build system is an entirely separate beast from Debian's build system. (And not everything compiles on Parabola, given it is a fork of Arch, which is bleeding edge by its own admission and gcc-4.8.0 can hardly be claimed to be 'stable,' as in able to build whatever you throw at it.)
OK, I don't actually know the answer because the package helpers handle all this for you. I just know where you're supposed to be able to find it (as I said I tinker).
My understanding of maint-guide is that << means strictly-less-than. So you are telling it that it is incompatible with and replaces anything less than 4.8.5. Which would seem to make little difference as the Trisquel repo is above that level already.
However, in parallel I have been experimenting on hello-debhelper which is the recommended learning package. I downloaded it with a
apt-get source hello-debhelper
cd hello-debhelper/tab/
and modded it to personalize the traditional greeting to "hello Leny\n"
Then did a
dpkg-source --commit
Leaving the release in debian/changelog unchanged when my editor came up (you need to read package debian-policy to know what to put there). According to maint-guide this is the file the actual package version / release etc is stored in. Then a
dpkg-buildpackage
cd ..
sudo dpkg -i hello-debhelperTAB
This installed the package, but
sudo apt-get update
sudo apt-get upgrade
wanted to replace it.
I then did
cd helloTAB
dch -i
Which gave me my editor with the release part of the package name which is in parens having a .1 appended to the end. I filled the changelog in as best I was able and built the package again with
dpkg-buildpackage
and installed the .deb from one directory above as before. This time I was not offered an update by apt-get update; apt-get upgrade. The problem is I don't know for sure if I would be offered an upgrade should the package be updated in the Trisquel repos.
But in reading the Debian Linux Kernel Handbook ( http://kernel-handbook.alioth.debian.org/ch-common-tasks.html ) this week I noticed they said that a ~ in the suffix indicates a pre-release version. So you might experiment with a suffix of ~6.0trisquel1 after any ubuntu string in debian/changelog which would be the pre-release suffix for the first Trisquelization. Then watch for DNS's updates (which aren't in any of the git repos I know of yet) arriving on another computer (or better setup a small virtual machine to test). Unless you've got some desperate passion to build a small repo at home and experiment that is. I've no idea about that.
I'd be interested to hear what you've done if you do get it to work.
Ok that sounds exactly like what I am looking for. I am going to follow your example step-by-step because I will remember it once I see it with my own eyes. I will take good notes too for easy reproduction down the road. I don't want a repo here. I don't have the space. I will copy all the debs in the archives to a folder on the data partitions so I don't have to hit the Trisquel servers if I decide to revert back.
I am a tinkerer too. I can afford to play with Trisquel on my desktop, because I've also got Parabola and a freed Gentoo on the desktop, as well as Trisquel on the netbook (which is perfect for it beyond words. I can't even imagine anything else on the netbook but Trisquel's KDE4 plasma netbook UI. I tried Gnome 3 and loved it but am totally addicted to opening terminals from whatever folder I happen to be in).
Even if the desktop does get hosed, I will have the deb archives for a quick reinstall and will tar up /etc too before diving in. I want to follow the same recipe for building Gentoo, ie, build gcc, then glibc, then binutils, install all 3, then rebuild them again in that order, and then rebuild the rest from the ground up. KDE4 on Trisquel is already light as a feather, but I am DYING to know if it can get even lighter with a recompile. So this is my summer project.
I tried this on Parabola. Gcc built perfectly. Glibc errored out. So I decided to recompile X, Qt4 and all of KDE instead. X built perfectly, but Qt4 errored out. It's not Parabola's fault. There is a reason gcc-4.6.3 is the base of Gentoo stable, instead of gcc-4.8.0. Parabola is an Arch fork, so there ya go.
Good luck with it! Like I said, distinctly non-trivial.
You might like to take a look at the debian-arm mailing list archives
and wiki for details of how to navigate the dependency cycle in the
fundamental packages. They've recently done a self hosted (i.e.
GNU/Linux based) port to aarch64 (arm64) using only a simulator
because there's no actual hardware yet. They'll have had all the
problems you're likely to face as it's the first Debian non-x86 self
host - they'll have had everything including the kitchen sink.
Also you might like to do some research if your 4 core has an AMD
processor before you try to build using it. Certainly in 64 bit
Intel processors feature more SSE vector instructions, which IMO is
the most likely way you'll get better performance. But IMO you're
unlikely to be able to host programs using them on an AMD box unless
the kernel features some instruction emulation kludge. Since you'd
only really need that for programs you don't have source for I doubt
it'd be much of a priority even for LKML. It's more kvm and qemu
territory.
Lastly big compilations are usually i/o bound, if you can afford to
augment your 4 core assuming it's a desktop with a cheap smallish SSD
do. I fitted one to my desktop for that purpose (putting the source
on it) and the CPU fan started going during compilations. Had to
clean the cooler :-).
Good luck again, and lots of fun.