|
Next: RFS: sem182 - Convenience library for working wit..
|
| Author |
Message |
External
Since: Jan 01, 2009
Posts: 5
|
(Msg. 1) Posted: Thu Jan 01, 2009 2:20 am
Post subject: Debian etch - Rebuilding a package from source.
Archived from groups: linux>debian>devel>mentors (more info?)
|
|
|
I'm not sure how to address the issue of reconfiguring official debs to
enable some option or other that may be of interest to me and not to the
general population and I hope I may be able to get some help on this
list.
I have often run into the case where the official debian package does
not support a configure option that I wish to enable and so far I just
downloaded the tarball & ran configure && make && make install.
Now that I am looking into debian-live in order to create a clone of my
work environment that I can carry around on external media such as DVD
or USB Flash Drive, I find that I pretty much need to generate my own
..deb's in order to include my customized versions into my live CD.
I read through to some of the Debian New Maintainer's Guide and that has
left me quite a bit overwhelmed. If I took this road, I would probably
need to stop what I'm doing on debian live for an extended period of
time to study debian packaging in depth.
I did find some shorter documents that provide simplified versions
focusing for instance on rebuilding an existing package such as:
http://www.debian-administration.org/articles/20/print
The trouble is that this article is not recent and I'm a bit concerned
that its contents may have been deprecated (new tools - e.g.).
What I have done so far is pretty much what is describe in the above:
. apt-get source ..
. build-dep ..
. debuild ..
. dpkg -i ..
The process appears to work - as tested on gnu/screen - when I'm just
recreating the same deb that I would install via apt-get.
One problem, though, is that since the build is pretty much automated,
I'm not sure how I could add --xxx configure options that override the
defaults. In particular after reading the man page I wasn't able to find
an option that would let me achieve this.
Hopefully, I don't have to go edit the configure.in file?
Another concern is what kind of naming standard I should/could adopt for
my custom .debs so that they integrate smoothly with the apt packaging
system. In other words.. in a way that will be easy to manage over time
and not interfere with possible future apt-get actions, such as upgrades
to a new release etc.
I do have a feeling that my questions are probably too general and may
even be the wrong questions.
If anyone feels I should look at this issue from a different angle, they
are welcome to correct me.
In any event Happy New Year to all.
Thanks!
CJ
--
To UNSUBSCRIBE, email to debian-mentors-REQUEST RemoveThis @lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster RemoveThis @lists.debian.org |
|
| Back to top |
|
 | |
External
Since: May 10, 2008
Posts: 7
|
(Msg. 2) Posted: Thu Jan 01, 2009 3:10 am
Post subject: Re: Debian etch - Rebuilding a package from source. [Login to view extended thread Info.]
Archived from groups: per prev. post (more info?)
|
|
|
Chris Jones wrote:
> What I have done so far is pretty much what is describe in the above:
>
> . apt-get source ..
> . build-dep ..
> . debuild ..
> . dpkg -i ..
>
> The process appears to work - as tested on gnu/screen - when I'm just
> recreating the same deb that I would install via apt-get.
>
That's a good procedure. It's what I do when I need to rebuild a package.
> One problem, though, is that since the build is pretty much automated,
> I'm not sure how I could add --xxx configure options that override the
> defaults. In particular after reading the man page I wasn't able to find
> an option that would let me achieve this.
>
The configure script gets called in debian/rules. Editing the file you
should be able to find a call to it and modify appropriately.
> Another concern is what kind of naming standard I should/could adopt for
> my custom .debs so that they integrate smoothly with the apt packaging
> system. In other words.. in a way that will be easy to manage over time
> and not interfere with possible future apt-get actions, such as upgrades
> to a new release etc.
>
One possibility is to increase the package revision and append something
like '~yourname0'. If the package is 1.4.5-3, you make
1.4.5-4~something0, which is greater than 1.4.5-3 but smaller than
1.4.5-4 or any newer upstream version. But there are other possibilities
regarding suffixes.
--
To UNSUBSCRIBE, email to debian-mentors-REQUEST RemoveThis @lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster RemoveThis @lists.debian.org |
|
| Back to top |
|
| |
External
Since: Aug 21, 2005
Posts: 247
|
(Msg. 3) Posted: Thu Jan 01, 2009 3:10 am
Post subject: Re: Debian etch - Rebuilding a package from source. [Login to view extended thread Info.]
Archived from groups: per prev. post (more info?)
|
|
|
On Wed, 31 Dec 2008 19:45:26 -0500, Chris Jones wrote:
> What I have done so far is pretty much what is describe in the above:
>
> . apt-get source ..
> . build-dep ..
> . debuild ..
> . dpkg -i ..
That's just how to do it, yes. 
> The process appears to work - as tested on gnu/screen - when I'm just
> recreating the same deb that I would install via apt-get.
>
> One problem, though, is that since the build is pretty much automated,
> I'm not sure how I could add --xxx configure options that override the
> defaults. In particular after reading the man page I wasn't able to find
> an option that would let me achieve this.
>
> Hopefully, I don't have to go edit the configure.in file?
Check out the debian/rules file. That is the file that controls the build
process.
> Another concern is what kind of naming standard I should/could adopt for
> my custom .debs so that they integrate smoothly with the apt packaging
> system. In other words.. in a way that will be easy to manage over time
> and not interfere with possible future apt-get actions, such as upgrades
> to a new release etc
I wouldn't try to rename the packages, but instead give them custom
version numbers. The version number can be changed by editng debian/
changelog; there is a very convenient tool called 'debchange' in the
'devscripts' package that will allow you to do things like:
$ debchange --local blah
Which will automatically add a new entry to the changelog, and invoke
your $EDITOR on it so that you can describe your changes in detail. The --
local option tells debchange to make this kind of change:
1.2-3 -> 1.2.3blah1
This version number will be greater than the version in Debian (so that
apt won't automatically replace your custom package with the official one
next time you perform an upgrade), but less than what the next version in
Debian _will_ be (so that apt will upgrade the package once a newer
version is available in Debian). If you also put the packages 'on hold'
then you can see that it's time to update your custom package by seeing
the 'packages held back' during an upgrade.
--
--
To UNSUBSCRIBE, email to debian-mentors-REQUEST DeleteThis @lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster DeleteThis @lists.debian.org |
|
| Back to top |
|
| |
External
Since: Jan 01, 2009
Posts: 5
|
(Msg. 4) Posted: Thu Jan 01, 2009 3:50 am
Post subject: Re: Debian etch - Rebuilding a package from source. [Login to view extended thread Info.]
Archived from groups: per prev. post (more info?)
|
|
|
On Wed, Dec 31, 2008 at 09:05:08PM EST, Sam Morris wrote:
> On Wed, 31 Dec 2008 19:45:26 -0500, Chris Jones wrote:
>
>
> > What I have done so far is pretty much what is described in the above:
> >
> > . apt-get source ..
> > . build-dep ..
> > . debuild ..
> > . dpkg -i ..
>
> That's just how to do it, yes.
Thanks!
One thing I can't afford to do is explore a blind alley for the next
couple of years and find out by accident that I was wasting my time.
> > The process appears to work - as tested on gnu/screen - when I'm just
> > recreating the same deb that I would install via apt-get.
> >
> > One problem, though, is that since the build is pretty much automated,
> > I'm not sure how I could add --xxx configure options that override the
> > defaults. In particular after reading the man page I wasn't able to find
> > an option that would let me achieve this.
> >
> > Hopefully, I don't have to go edit the configure.in file?
>
> Check out the debian/rules file. That is the file that controls the build
> process.
Thanks for the lead .. does look like there's no getting away from
learning the Maintainers Guide after all..
But since some of my customization is in the way of scripts .. I realize
it's not just a matter of rebuilding .. I will have to create new
packages anyway .. and thus I will have to learn at least the basics of
debian packaging.
> > Another concern is what kind of naming standard I should/could adopt for
> > my custom .debs so that they integrate smoothly with the apt packaging
> > system. In other words.. in a way that will be easy to manage over time
> > and not interfere with possible future apt-get actions, such as upgrades
> > to a new release etc
>
> I wouldn't try to rename the packages, but instead give them custom
> version numbers.
Yes .. that 's exactly what I had in mind.
> The version number can be changed by editng debian/ changelog; there
> is a very convenient tool called 'debchange' in the 'devscripts'
> package that will allow you to do things like:
>
> $ debchange --local blah
>
> Which will automatically add a new entry to the changelog, and invoke
> your $EDITOR on it so that you can describe your changes in detail.
> The -- local option tells debchange to make this kind of change:
>
> 1.2-3 -> 1.2.3blah1
Great! Will look into that when the party is over .. when I'm sober
again..
> This version number will be greater than the version in Debian (so
> that apt won't automatically replace your custom package with the
> official one next time you perform an upgrade), but less than what the
> next version in Debian _will_ be (so that apt will upgrade the package
> once a newer version is available in Debian). If you also put the
> packages 'on hold' then you can see that it's time to update your
> custom package by seeing the 'packages held back' during an upgrade.
Yes. That's what I dimly was thinking about ..
Happy New Year .. and thanks much for prompt reply.
CJ
--
To UNSUBSCRIBE, email to debian-mentors-REQUEST.DeleteThis@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster.DeleteThis@lists.debian.org |
|
| Back to top |
|
| |
External
Since: Jan 01, 2009
Posts: 5
|
(Msg. 5) Posted: Thu Jan 01, 2009 4:00 am
Post subject: Re: Debian etch - Rebuilding a package from source. [Login to view extended thread Info.]
Archived from groups: per prev. post (more info?)
|
|
|
On Wed, Dec 31, 2008 at 08:38:45PM EST, Eduardo M KALINOWSKI wrote:
> Chris Jones wrote:
> >What I have done so far is pretty much what is described in the above:
> >
> > . apt-get source ..
> > . build-dep ..
> > . debuild ..
> > . dpkg -i ..
> >
> >The process appears to work - as tested on gnu/screen - when I'm just
> >recreating the same deb that I would install via apt-get.
> >
>
> That's a good procedure. It's what I do when I need to rebuild a package.
Thanks!
> >One problem, though, is that since the build is pretty much automated,
> >I'm not sure how I could add --xxx configure options that override the
> >defaults. In particular after reading the man page I wasn't able to find
> >an option that would let me achieve this.
> >
>
> The configure script gets called in debian/rules. Editing the file you
> should be able to find a call to it and modify appropriately.
Found it!
And sure enough, the screen 256 colors configure option I was looking
for is commented out.
> >Another concern is what kind of naming standard I should/could adopt for
> >my custom .debs so that they integrate smoothly with the apt packaging
> >system. In other words.. in a way that will be easy to manage over time
> >and not interfere with possible future apt-get actions, such as upgrades
> >to a new release etc.
> >
>
> One possibility is to increase the package revision and append something
> like '~yourname0'. If the package is 1.4.5-3, you make
> 1.4.5-4~something0, which is greater than 1.4.5-3 but smaller than
> 1.4.5-4 or any newer upstream version. But there are other possibilities
> regarding suffixes.
Thanks.
When you plan on maintaining your custom stuff over time, that seems to
be a fundamental issue .. and deciding on the right scheme to start off
with is likely something that will save me multiple headaches later on.
Happy New Year and much thanks for your timely reply!
CJ
--
To UNSUBSCRIBE, email to debian-mentors-REQUEST.DeleteThis@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster.DeleteThis@lists.debian.org |
|
| Back to top |
|
| |
External
Since: Jan 01, 2009
Posts: 5
|
(Msg. 6) Posted: Thu Jan 01, 2009 8:10 pm
Post subject: Re: Debian etch - Rebuilding a package from source. [Login to view extended thread Info.]
Archived from groups: per prev. post (more info?)
|
|
|
On Wed, Dec 31, 2008 at 11:16:46PM EST, Boyd Stephen Smith Jr. wrote:
> On Wednesday 2008 December 31 18:45:26 Chris Jones wrote:
> > What I have done so far is pretty much what is described in the above:
> >
> > . apt-get source ..
> > . build-dep ..
> > . debuild ..
> > . dpkg -i ..
> I'll go ahead and disagree with the others, slightly. This is fine
> for packages you are only going to use yourself, or only install on a
> system with the same packages installed as your current system. It
> also "dirties" your system with the Build-Depends of the package.
>
> _It_ _will_ _work_ and the packages that come out will be completely
> valid. However, making a pbuilder(cowbuilder) environment will make
> sure your packages build from source cleanly, and only depend on
> packages available from a specific flavor of debian (Etch/stable,
> Lenny/unstable, Sid/unstable).
Yes, I also saw pbuilder/cowbuilder mentioned in several places.
I also ran into dh-make and dpkg-buildpackage, and though I did not go
into details in my initial post, the existence of such a variety of
tools is the main reason I posted here.
I did look for a document that would attempt to put the different tools
into perspective and I was not that surprised to come up empty-handed
since it would be a rare individual indeed who has used all of them and
would be able to recommend one best adapted to your needs.
> It will also isolate the build process into a chroot, so that you
> won't inadvertently forget to list a Build-Depend that you just happen
> to have installed and won't have Build-Depends installed on your
> running system (which I think is good).
Sounds like a very useful feature but then since debian-live also builds
its target in a chroot, I'm beginning to wonder whether it provides some
way to integrate custom deb's that I have overlooked.
> If packaging is just a means to an end, skip the pbuilder for now.
> However, if you want to make high-quality package that might be
> accepted into Debian, a pbuilder environment is a must.
What would the tradeoff be? Is it a matter of a steeper learning curve?
Does it require more resources such as disk-space?
> > One problem, though, is that since the build is pretty much
> > automated, I'm not sure how I could add --xxx configure options that
> > override the defaults. In particular after reading the man page I
> > wasn't able to find an option that would let me achieve this.
> As with others, I'll just point you at the debian/rules file. That's
> the starting point for the build process, so it will normally be your
> starting point. Depending on the package, there may also be a file
> describing the build process and how to modify/maintain it. If so,
> read that along-side the debian/rules file.
Thanks, I would probably have missed that.
> Trying to modify the build process without reading and understanding
> (at some level) the debian/rules file is similar to trying to modify
> the build process of a project that uses a plain Makefile without
> reading that.
>
> > Another concern is what kind of naming standard I should/could adopt
> > for my custom .debs so that they integrate smoothly with the apt
> > packaging system. In other words.. in a way that will be easy to
> > manage over time and not interfere with possible future apt-get
> > actions, such as upgrades to a new release etc.
>
> As other have mentioned, using a different version instead of a
> different name will allow clean upgrades. The normal way to do this
> is "${debian_version}yourname0" for the first private version, then
> increment the number at the end for each subsequent private version
> based on the same Debian version. E.g. 1.2-2 -> 1.2-2yourname0.
>
> If you'd prefer your package *not* be upgraded when there is a new
> Debian version, but *be* upgraded when there is a new upstream version
> you could use "${upstream_version}+yourname0-${debian_suffix}", e.g.
> 1.2-2 -> 1.2+yourname0-2.
Not to mention that at some point or other there may be cases where I
need different versions of my custom packages.
> In both cases you can use "holds" or apt_preferences(5) to prefer your
> version over the newer version.
>
> If you'd prefer your package to not be upgraded at all, you should
> rename the package and then have your package Provides the old package
> name. This may not work seemlessly if there are versioned Depends of
> the old package name, but should work well, especially if you continue
> to follow the Debian conventions for package versioning, e.g. by using
> one of the previous two paragraphs to guide your version numbers.
>
> IIRC, devscripts has a script/program to compare version numbers if
> you aren't sure which one the "newer"/"greater" than another.
> --
> Boyd Stephen Smith Jr. ,= ,-_-. =.
> bss.TakeThisOut@iguanasuicide.net ((_/)o o(\_))
> ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
> http://iguanasuicide.net/ \_/
Thanks for all the details.
CJ
--
To UNSUBSCRIBE, email to debian-mentors-REQUEST.TakeThisOut@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster.TakeThisOut@lists.debian.org |
|
| Back to top |
|
| |
External
Since: Jan 01, 2009
Posts: 5
|
(Msg. 7) Posted: Sun Jan 04, 2009 5:10 am
Post subject: Re: Debian etch - Rebuilding a package from source. [Login to view extended thread Info.]
Archived from groups: per prev. post (more info?)
|
|
|
On Fri, Jan 02, 2009 at 12:40:05AM EST, Boyd Stephen Smith Jr. wrote:
> On Thursday 01 January 2009, Chris Jones <cjns1989.RemoveThis@gmail.com> wrote
> about 'Re: Debian etch - Rebuilding a package from source.':
> >On Wed, Dec 31, 2008 at 11:16:46PM EST, Boyd Stephen Smith Jr. wrote:
> >> On Wednesday 2008 December 31 18:45:26 Chris Jones wrote:
> >> > What I have done so far is pretty much what is described in the
> >> > above:
> >> >
> >> > . apt-get source ..
>
> You might also look at apt-src.
aargh .. another one ..
I followed your advice & took it out for a test drive but it looks like
it's a bit "higher level" that apt-get source in a sense.. and may as a
result require a better understanding of the debian system. IOW, it
appears to do some extra stuff whose meaning and implications are not
clear to me at this point.
> >> > . build-dep ..
> >> > . debuild ..
> >> > . dpkg -i ..
I found by trial and error .. and a bit of serendipity / poking around
that I was missing a couple of steps and an iteration.
One step that's missing from the above is running debclean .. if you
don't get it quite right first time around, that is.. or change your
configure options, for instance..
For something a little less trivial one may have to iterate a number of
times the {fix error(s) - debclean - debuild - dpkg -i - test} cycle.
As I understand it, I need a debclean (or a debchange) in my loop in
order to have the ensuing debuild take my changes into account.. in
this particular scenario I don't think I should have been creating new
versions since all I was changing was fixing typos.
[..]
> That may be the case. I do not currently have any experience with
> debian-live, so I couldn't usefully comment.
As you stated below, learning to build packages is a means to an end at
this point.
But then, when I am bored with debian-live, hopefully I'll have learned
some more generally useful stuff.
> >> If packaging is just a means to an end, skip the pbuilder for now.
> >> However, if you want to make high-quality package that might be
> >> accepted into Debian, a pbuilder environment is a must.
> >What would the tradeoff be? Is it a matter of a steeper learning
> >curve? Does it require more resources such as disk-space?
> Yes, a bit steeper, mainly just because you'll be adding yet another
> tool to your toolbox.
> Yes, you'll need enough persistent disk-space for a base Debian system
> that will reside (possibly compressed) in /var/cache/pbuilder. During
> the build, the chroot will grow as it will be uncompressed, if
> compressed, and download and install all the Build-Depends and of
> course there is the build process itself. You'll need enough disk
> space for this processes, but after the build is complete most of this
> disk space will be reclaimed. What is not reclaimed is the downloaded
> package files which will be put into /var/cache/pbuilder/aptcache so
> that later pbuilder invocations will not have to re-download those
> packages.
Also sounds like another "resource" that pbuilder may require is a
somewhat bigger chunk of my personal time.
Thank you gentlemen for helping me get started with debian packaging!
CJ
--
To UNSUBSCRIBE, email to debian-mentors-REQUEST.RemoveThis@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster.RemoveThis@lists.debian.org |
|
| Back to top |
|
| |
| Related Topics: | From local source tree to Debian package - Howdy all, Most program packages start life as a single source code tree, with everything conveniently located under a package-specific hierarchy: programs, library modules, runtime configuration files, data files, etc. The programs need to allow for..
DebPPA: Debian Personal Package Archive - Hi, I would like to create something like the Ubuntu Personal Package Archive (PPA), but for Debian. It should be a single package, which one just installs and it just woks. My current code is here: http://code.google.com/p/debppa/ It's written in..
RFS: debian-builder (updated package) - Dear mentors, I am looking for a sponsor for the new version 1.8 of my package "debian-builder". It builds these binary packages: debian-builder - Rebuild Debian packages from source code The package appears to be lintian clean. The upload ...
RFS: file-browser-applet (new upstream release of package .. - -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dear mentors, I am looking for a sponsor for the new version 0.5.9-1 of my package "file-browser-applet". It builds these binary packages: file-browser-applet - browse and open files on your comp...
RFS: falcon package (ITP:Bug#460591); source package - -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dear mentors, I have realized a first tentative packaging; complete source package can be downloaded here: http://www.falconpl.org/downloads/0.8.7/falcon-0.8.7.SourceDebian.tar.gz It is a sightly modifie... |
|
You can post new topics in this forum
You can reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
Hot
Bloated Email? DetachPipe for Outlook
Mac
Linux
Games
PDA
Mobile
FAQ
Search
Profile
Private Messages
Log in
Linux Forums
RSS