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

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

Building my own packages

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

Contents

  Building my own packages Victor Sudakov <vas@sibptus.ru> - 2020-11-04 15:40 +0100
    Re: Building my own packages Reco <recoverym4n@enotuniq.net> - 2020-11-04 16:40 +0100
      Re: Building my own packages Victor Sudakov <vas@sibptus.ru> - 2020-11-05 05:50 +0100
    Re: Building my own packages songbird <songbird@anthive.com> - 2020-11-04 17:50 +0100
      Re: Building my own packages Victor Sudakov <vas@sibptus.ru> - 2020-11-05 06:00 +0100
        Re: Building my own packages Linux-Fan <Ma_Sys.ma@web.de> - 2020-11-05 23:50 +0100
          Re: Building my own packages Victor Sudakov <vas@sibptus.ru> - 2020-11-11 06:20 +0100
            Re: Building my own packages Andrei POPESCU <andreimpopescu@gmail.com> - 2020-11-11 09:20 +0100
        Re: Building my own packages deloptes <deloptes@gmail.com> - 2020-11-06 08:40 +0100
          Re: Building my own packages Victor Sudakov <vas@sibptus.ru> - 2020-11-11 06:30 +0100
            Re: Building my own packages deloptes <deloptes@gmail.com> - 2020-11-11 08:00 +0100
            Re: Building my own packages Andrei POPESCU <andreimpopescu@gmail.com> - 2020-11-11 09:30 +0100
            Re: Building my own packages <tomas@tuxteam.de> - 2020-11-11 09:30 +0100
    Re: Building my own packages "Thomas Schmitt" <scdbackup@gmx.net> - 2020-11-04 19:00 +0100
      Re: Building my own packages Victor Sudakov <vas@sibptus.ru> - 2020-11-05 06:10 +0100
        Re: Building my own packages "Thomas Schmitt" <scdbackup@gmx.net> - 2020-11-05 08:30 +0100
    Re: Building my own packages <tomas@tuxteam.de> - 2020-11-04 22:30 +0100
      Re: Building my own packages Victor Sudakov <vas@sibptus.ru> - 2020-11-05 06:40 +0100
        Re: Building my own packages <tomas@tuxteam.de> - 2020-11-05 09:30 +0100
          Re: Building my own packages Victor Sudakov <vas@sibptus.ru> - 2020-11-05 17:00 +0100
            Re: Building my own packages <tomas@tuxteam.de> - 2020-11-05 17:20 +0100
              Re: Building my own packages Stefan Monnier <monnier@iro.umontreal.ca> - 2020-11-05 18:20 +0100
                Re: Building my own packages <tomas@tuxteam.de> - 2020-11-05 19:30 +0100
    Re: Building my own packages Alex Mestiashvili <amestia@rsh2.donotuse.de> - 2020-11-05 11:20 +0100

Page 1 of 2  [1] 2  Next page →

#228454 — Building my own packages

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

Dear Colleagues,

As a person with the FreeBSD background, I'm used to building my own
packages with the exact build options I need (those include exim, nginx,
samba, clamav and many others). FreeBSD has a good infrastructure for
this (ports tree, poudriere et al.)

Where can I learn to do a similar thing for Debian? I'd like to have my
own package repository which:

1. Keeps my local patches and configure/build options.
2. Gets updated and recompiled when the main Debian repository gets updated.
3. Can have a higher preference for my Debian systems than the default Debian repositories.

I know this can be done because I use some vendor repositories (zabbix,
consul etc) but I need the tools and knowledge.

What would you advise me to read?

-- 
Victor Sudakov,  VAS4-RIPE, VAS47-RIPN
2:5005/49@fidonet http://vas.tomsk.ru/

[toc] | [next] | [standalone]

#228457

	Hi.

On Wed, Nov 04, 2020 at 09:32:31PM +0700, Victor Sudakov wrote:
> Where can I learn to do a similar thing for Debian? I'd like to have my
> own package repository which:
> 
> 1. Keeps my local patches and configure/build options.
> 2. Gets updated and recompiled when the main Debian repository gets updated.
> 3. Can have a higher preference for my Debian systems than the default Debian repositories.

apt-build can do 1 and 3.
2 is tricky.

And the trick here lies in the fact that building software should use a
controlled, reproducible and deterministic environment (pbuilder,
cowbuilder, buildd to name a few), and not a live OS installation with
assorted packages and customizations.
Assuming, of course, that you need whatever you want to build working,
not merely compiled somehow and installed somewhere.

But, since you're accustomed to do things FreeBSD way (and building
something in controlled environment isn't something they do or promote)
- just assume that apt-build can do updates too.

Reco

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

#228472

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

Reco wrote:
> 	Hi.
> 
> On Wed, Nov 04, 2020 at 09:32:31PM +0700, Victor Sudakov wrote:
> > Where can I learn to do a similar thing for Debian? I'd like to have my
> > own package repository which:
> > 
> > 1. Keeps my local patches and configure/build options.
> > 2. Gets updated and recompiled when the main Debian repository gets updated.
> > 3. Can have a higher preference for my Debian systems than the default Debian repositories.
> 
> apt-build can do 1 and 3.
> 2 is tricky.
> 
> And the trick here lies in the fact that building software should use a
> controlled, reproducible and deterministic environment (pbuilder,
> cowbuilder, buildd to name a few), and not a live OS installation with
> assorted packages and customizations.

Most certainly yes. In FreeBSD, poudriere provides this controlled
environment in the form of reference jails.

> Assuming, of course, that you need whatever you want to build working,
> not merely compiled somehow and installed somewhere.

Sure. 

> 
> But, since you're accustomed to do things FreeBSD way (and building
> something in controlled environment isn't something they do or promote)

This is incorrect.

> - just assume that apt-build can do updates too.
> 

I'll take a look at it but from what you have written above, it's
probably not what I am looking for. From the man page, it looks more
like FreeBSD's portmaster ("fetch the source and build/install right
here for this particular system").

I would like for my custom packages to form a repo I could use from
several Debian systems.

-- 
Victor Sudakov,  VAS4-RIPE, VAS47-RIPN
2:5005/49@fidonet http://vas.tomsk.ru/

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

#228458

Victor Sudakov wrote:

> Dear Colleagues,
>
> As a person with the FreeBSD background, I'm used to building my own
> packages with the exact build options I need (those include exim, nginx,
> samba, clamav and many others). FreeBSD has a good infrastructure for
> this (ports tree, poudriere et al.)
>
> Where can I learn to do a similar thing for Debian? I'd like to have my
> own package repository which:
>
> 1. Keeps my local patches and configure/build options.
> 2. Gets updated and recompiled when the main Debian repository gets updated.
> 3. Can have a higher preference for my Debian systems than the default Debi=
> an repositories.
>
> I know this can be done because I use some vendor repositories (zabbix,
> consul etc) but I need the tools and knowledge.
>
> What would you advise me to read?

  there is a ton of information under:

  https://www.debian.org/devel/


  what you want is possible, but it really gets harder
or easier if the package you are interested in is already
done by someone else, then you can just get the source
code for yourself that has already had most of the work
done to it up to whatever standards the debian packager
has and you can go from there.  the other aspect is if
the package is required or not so you can't remove it
without removing a lot of other things.  if it is a leaf
package or one that can be somewhat self-contained then
you can just remove the debian version and put your own
in the place and set up a watch on the repository to
see when changes happen.


  songbird

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

#228473

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

songbird wrote:
> 
> > Dear Colleagues,
> >
> > As a person with the FreeBSD background, I'm used to building my own
> > packages with the exact build options I need (those include exim, nginx,
> > samba, clamav and many others). FreeBSD has a good infrastructure for
> > this (ports tree, poudriere et al.)
> >
> > Where can I learn to do a similar thing for Debian? I'd like to have my
> > own package repository which:
> >
> > 1. Keeps my local patches and configure/build options.
> > 2. Gets updated and recompiled when the main Debian repository gets updated.
> > 3. Can have a higher preference for my Debian systems than the default Debi=
> > an repositories.
> >
> > I know this can be done because I use some vendor repositories (zabbix,
> > consul etc) but I need the tools and knowledge.
> >
> > What would you advise me to read?
> 
>   there is a ton of information under:
> 
>   https://www.debian.org/devel/

The problem is I don't need a ton of information :-) I need to hear from
someone who has already done that for themselves: "I use such and such
tools, and publish my repo this way..."

>   what you want is possible, but it really gets harder
> or easier if the package you are interested in is already
> done by someone else, then you can just get the source
> code for yourself that has already had most of the work
> done to it up to whatever standards the debian packager
> has and you can go from there.  the other aspect is if
> the package is required or not so you can't remove it
> without removing a lot of other things.  if it is a leaf
> package or one that can be somewhat self-contained then
> you can just remove the debian version and put your own
> in the place and set up a watch on the repository to
> see when changes happen.

I have no doubt there are many such tricky things, that's why I'm
looking for a tutorial.

-- 
Victor Sudakov,  VAS4-RIPE, VAS47-RIPN
2:5005/49@fidonet http://vas.tomsk.ru/

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

#228492

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

Victor Sudakov writes:

> songbird wrote:

[...]

> > > Where can I learn to do a similar thing for Debian? I'd like to have my
> > > own package repository which:
> > >
> > > 1. Keeps my local patches and configure/build options.
> > > 2. Gets updated and recompiled when the main Debian repository gets  
> > > updated.
> > > 3. Can have a higher preference for my Debian systems than the default  
> > > Debian repositories.
> > >
> > > I know this can be done because I use some vendor repositories (zabbix,
> > > consul etc) but I need the tools and knowledge.
> > >
> > > What would you advise me to read?
> >
> >   there is a ton of information under:
> >
> >   https://www.debian.org/devel/
>
> The problem is I don't need a ton of information :-) I need to hear from
> someone who has already done that for themselves: "I use such and such
> tools, and publish my repo this way..."

[...]

> > in the place and set up a watch on the repository to
> > see when changes happen.
>
> I have no doubt there are many such tricky things, that's why I'm
> looking for a tutorial.

[...]

Hello,

I am among those who have done something similar, although with slightly  
different focus:

 * For me, it is mostly not to change options of existing packages but rather
   to add some packages that are not there yet (at all)
 * Additionally, I store a lot of configuration
 * I only upgrade from upstream on rare occasions, thus I have not automated
   that part thoroughly. The commits from "Oct 27, 2020" here show
   how I did an upgrade: https://github.com/m7a/lp-cone/commits/master

For my use case, I combine the following tools:

 * debuild   (Debian package building)
 * reprepro  (Custom repository)
 * ant       (generic build tool)
 * Docker¹   (chroot-like environment)
 * git       (for storing metadata and my own source code)
 * Perl      (to tie it all together)

My idea is to have one git repository per package and inside that, the  
package's metadata is "wholly" described by a single `build.xml` file for `ant`.

Working on package is mostly done by modifying the files in the git  
repository and then tiggering automatic builds by committing the current  
state of work (no need to upload anything to a server, the system uses the  
local file system).

I am really unsure whether my approach is anywhere near what you need, but I  
have automated almost all of the actual packaging stuff including the  
creation of a repository, the invocation of Debian build tools, the  
synchronization with the repository, the creation of a clean build  
environment... so maybe it can serve as a "formal tutorial" i.e. some code  
to look at, that does all the necessary steps.

Beware that it is a simplified version of the story though -- the packages  
created by my system are not suited for inclusion in Debian as-is (still  
pondering how to achieve that one day...).

Here is the documentation of all components:

 * https://masysma.lima-city.de/32/masysmaci_main.xhtml
 * https://masysma.lima-city.de/32/masysmaci_build.xhtml
 * https://masysma.lima-city.de/32/masysmaci_pkgsync.xhtml
 * https://masysma.lima-city.de/11/maartifact.xhtml

This marks my second approach to automate the packaging. Before that, I used  
a script called `mdpc` (1.0) which I posted to this mailing list at the time it  
was written. Afterwards, it did not really change anymore... and it works  
until today “mostly” -- for instance, it is highly dependent on the host  
system and some of its functions have not been used for at least a year...:  
https://lists.debian.org/debian-user/2013/08/msg00042.html

¹) Debian package `docker.io`. Note: Docker is a good substitute for most  
chroot uses (and many VM uses, too), but it loses much of their  
lightweightness and running Docker as regular user is still experimental (I  
did not try it yet...). Additionally, it is one of the more complicated  
tools out there...

HTH
Linux-Fan

öö

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

#228546

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

Linux-Fan wrote:

[dd]

> 
> Here is the documentation of all components:
> 
> * https://masysma.lima-city.de/32/masysmaci_main.xhtml
> * https://masysma.lima-city.de/32/masysmaci_build.xhtml
> * https://masysma.lima-city.de/32/masysmaci_pkgsync.xhtml
> * https://masysma.lima-city.de/11/maartifact.xhtml

Thank you, Linux-Fan, I've read the documentation and your CI/CD system
seems impressive ... and a bit overwhelming. I don't think I need such a
degree of automation. But speaking of its educational value, thanks
again.

It's strange that there is nothing (or I have not found yet) as
intuitive and working mostly OOTB like FreeBSD's poudriere.

-- 
Victor Sudakov,  VAS4-RIPE, VAS47-RIPN
2:5005/49@fidonet http://vas.tomsk.ru/

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

#228552

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

On Mi, 11 nov 20, 12:15:07, Victor Sudakov wrote:
> 
> It's strange that there is nothing (or I have not found yet) as
> intuitive and working mostly OOTB like FreeBSD's poudriere.

I'm guessing Debian is primarily addressing users who are happy with 
getting the packages pre-compiled for them.

Those who do a lot of package building are probably better served by 
Gentoo or Arch.

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser

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

#228497

Victor Sudakov wrote:

> The problem is I don't need a ton of information :-) I need to hear from
> someone who has already done that for themselves: "I use such and such
> tools, and publish my repo this way..."

Well, I use debuild to build and reprepro to maintain a local repository of
former KDE3 now called TDE.
I do not build automatically but from time to time I pull changes and build
the packages. Because there are dependencies it depends which package
changes this affects other packages. For that reason I created a Makefile
(actually few of them that complement each other).
You have to rebuild all dependencies if you rebuild one package. You simply
can not just build and replace a package in production environment without
testing it, making a backup or whatever.
I guess the answer to your question is that there is no such out of the box
tool, but you need something specific to your setup.
Also consider the number of debian packages - You surely need a small
subset - again you have to configure this for yourself.
I guess all here would agree that with the release model of Debian you have
a lot of freedom (stable-testing-experimental) to save time on rebuilding
packages, otherwise it is called Gentoo.
On top of that don't forget that debian packages include patches and fixes
specific to debian.

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

#228548

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

deloptes wrote:
> 
> > The problem is I don't need a ton of information :-) I need to hear from
> > someone who has already done that for themselves: "I use such and such
> > tools, and publish my repo this way..."
> 
> Well, I use debuild to build and reprepro to maintain a local repository of
> former KDE3 now called TDE.

I've already tried reprepro and it seems to do its job well in publishing
the packages I feed to it. Now it's building time.

> I do not build automatically but from time to time I pull changes and build
> the packages. Because there are dependencies it depends which package
> changes this affects other packages. For that reason I created a Makefile
> (actually few of them that complement each other).
> You have to rebuild all dependencies if you rebuild one package. You simply
> can not just build and replace a package in production environment without
> testing it, making a backup or whatever.

There lies the point which I don't completely understand yet. If I want
to build a php or exim4 package with my own build options, to what
extent should I also build their dependencies? And how do I name those
packages so that they coexist with the default Debian ones?

OTOH, sometimes I would want my package (e.g. tcpdump with my patch) to
override Debian's one.

> I guess the answer to your question is that there is no such out of the box
> tool, but you need something specific to your setup.

Pity. I wonder what those people and companies use who publish their own
repos/products for Debian (Hashicorp, PostgreSQL, Zabbix etc).

> Also consider the number of debian packages - You surely need a small
> subset - again you have to configure this for yourself.
> I guess all here would agree that with the release model of Debian you have
> a lot of freedom (stable-testing-experimental) to save time on rebuilding
> packages, otherwise it is called Gentoo.

Can I use some of the Gentoo ecosystem on Debian, for a few selected
packages? Or maybe snap is for me?

> On top of that don't forget that debian packages include patches and fixes
> specific to debian.

I hoped to download Debian's source packages (already including all
Debian-specific stuff) and just rebuild them with minimal
changes/patches.

-- 
Victor Sudakov,  VAS4-RIPE, VAS47-RIPN
2:5005/49@fidonet http://vas.tomsk.ru/

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

#228549

Victor Sudakov wrote:

>> Well, I use debuild to build and reprepro to maintain a local repository
>> of former KDE3 now called TDE.
> 
> I've already tried reprepro and it seems to do its job well in publishing
> the packages I feed to it. Now it's building time.
> 
>> I do not build automatically but from time to time I pull changes and
>> build the packages. Because there are dependencies it depends which
>> package changes this affects other packages. For that reason I created a
>> Makefile (actually few of them that complement each other).
>> You have to rebuild all dependencies if you rebuild one package. You
>> simply can not just build and replace a package in production environment
>> without testing it, making a backup or whatever.
> 
> There lies the point which I don't completely understand yet. If I want
> to build a php or exim4 package with my own build options, to what
> extent should I also build their dependencies? And how do I name those
> packages so that they coexist with the default Debian ones?
> 
You just put here questions that one can not answer. Answer of these
questions will help you define your use case and this will help you define
the steps to complete the requirements.
In general you should build so that there is compatibility and no a
coexistence but replace the original package (read the debian packaging
doc)
If you want coexistence of packages you should change for example the
install prefix. Now for exim you can not have two exim processes running
the same time on same port. You should also consider modifying ports etc.

> OTOH, sometimes I would want my package (e.g. tcpdump with my patch) to
> override Debian's one.
> 

yes - it depends on the use case

>> I guess the answer to your question is that there is no such out of the
>> box tool, but you need something specific to your setup.
> 
> Pity. I wonder what those people and companies use who publish their own
> repos/products for Debian (Hashicorp, PostgreSQL, Zabbix etc).
> 

It is not the tools, but the final product that matters. At the end you get
a package to install. The packagers take care of the details. There are
many ways to reach the goal.

>> Also consider the number of debian packages - You surely need a small
>> subset - again you have to configure this for yourself.
>> I guess all here would agree that with the release model of Debian you
>> have a lot of freedom (stable-testing-experimental) to save time on
>> rebuilding packages, otherwise it is called Gentoo.
> 
> Can I use some of the Gentoo ecosystem on Debian, for a few selected
> packages? Or maybe snap is for me?
> 

I do not think so. I don't know snap. I learn  recently flatpack appeared,
but never tried it.

>> On top of that don't forget that debian packages include patches and
>> fixes specific to debian.
> 
> I hoped to download Debian's source packages (already including all
> Debian-specific stuff) and just rebuild them with minimal
> changes/patches.

Then I would advice to start with https://wiki.debian.org/Packaging

but remember it depends which package you change. If it is library all the
packages depending on this library might need recompiling which is not
exactly easy task.

I hope you do it in a test environment like virtual machine first. I build
in chroot, publish the packages with reprepro and install to test first in
a VM. If it works well I have tftp boot setup where I install the packages
in chroot on the server, I boot the machine from tftp and test. If this
works I boot from disk and install the packages for production use.
This is industry quality process for testing and acceptance.

 

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

#228554

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

On Mi, 11 nov 20, 12:27:48, Victor Sudakov wrote:
> deloptes wrote:
> > 
> > > The problem is I don't need a ton of information :-) I need to hear from
> > > someone who has already done that for themselves: "I use such and such
> > > tools, and publish my repo this way..."
> > 
> > Well, I use debuild to build and reprepro to maintain a local repository of
> > former KDE3 now called TDE.
> 
> I've already tried reprepro and it seems to do its job well in publishing
> the packages I feed to it. Now it's building time.
> 
> > I do not build automatically but from time to time I pull changes and build
> > the packages. Because there are dependencies it depends which package
> > changes this affects other packages. For that reason I created a Makefile
> > (actually few of them that complement each other).
> > You have to rebuild all dependencies if you rebuild one package. You simply
> > can not just build and replace a package in production environment without
> > testing it, making a backup or whatever.
> 
> There lies the point which I don't completely understand yet. If I want
> to build a php or exim4 package with my own build options, to what
> extent should I also build their dependencies?

You only need to build their dependencies if you make changes to them.

> And how do I name those
> packages so that they coexist with the default Debian ones?

Any change in the package name would do.

> OTOH, sometimes I would want my package (e.g. tcpdump with my patch) to
> override Debian's one.

In this case you make your package have a higher version. For most cases 
it is sufficient to change the package version to something like (using 
current tcpdump from buster as example):

    4.9.3-1~deb10u1+patched

    (use whatever you like after the +)

This way APT will prioritise your package until a ~deb10u2 (e.g. in case 
of a security update) is published. You could use that as a trigger for 
your build system to reapply your patch and publish the updated package 
in your own repository.

> > I guess the answer to your question is that there is no such out of the box
> > tool, but you need something specific to your setup.
> 
> Pity. I wonder what those people and companies use who publish their own
> repos/products for Debian (Hashicorp, PostgreSQL, Zabbix etc).

The use case is significantly different as all those upstreams are 
typically publishing packages for several distros.
 
> I hoped to download Debian's source packages (already including all
> Debian-specific stuff) and just rebuild them with minimal
> changes/patches.

That's quite easy to do with (from memory, it's been a while since I did 
this):

    apt source <binary-package>

    apt build-dep <binary-package>
    
    # apply patch, change version, etc.
    
    dpkg-buildpackage <whatever>
    
    dpkg -i <rebuild-package.deb>


Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser

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

#228556

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

On Wed, Nov 11, 2020 at 12:27:48PM +0700, Victor Sudakov wrote:
> deloptes wrote:

[...]

> > You have to rebuild all dependencies if you rebuild one package. You simply
> > can not just build and replace a package in production environment without
> > testing it, making a backup or whatever.
> 
> There lies the point which I don't completely understand yet. If I want
> to build a php or exim4 package with my own build options, to what
> extent should I also build their dependencies? And how do I name those
> packages so that they coexist with the default Debian ones?

I think deloptes went a bit overboard with this.

I'd say... it depends. If you're building a package targeted at a
specific distro suite and just change the log level, for example,
you'd be wasting your time. If, OTOH, what you're changing is some
compiler option which affects the ABI towards a library, you won't
be well advised to use the distro's binary package for said
lib. You gota re-build that dependency, no?

Between those two (extreme) examples lies our real world, full of
shades and facets, which makes our lives "interesting".

In short, you gotta know what you're doing.

If you are sitting on top of a huge heap of manure and haven't
got the time to understad, then, yes, you have to follow the
path outlined by deloptes.

I tend to leave environments of that kind sooner latter than
later: they not only treat their computers like cattle, they
tend to treat their people that way, too.

Cheers
 - t

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

#228460

Hi,

Victor Sudakov wrote:
> As a person with the FreeBSD background, I'm used to building my own
> packages with the exact build options I need [...]
> What would you advise me to read?

Since no Debian Developers answered yet, i propose to read
  https://www.debian.org/doc/manuals/maint-guide/
and look for examples in
  https://tracker.debian.org/pkg/$package_name
and the "tools" and "box" icons to the left under "versioned links".
Like
  https://tracker.debian.org/media/packages/libi/libisoburn/rules-1.5.2-1
  https://tracker.debian.org/media/packages/libi/libisoburn/control-1.5.2-1


Have a nice day :)

Thomas

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

#228474

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

Thomas Schmitt wrote:
> 
> Victor Sudakov wrote:
> > As a person with the FreeBSD background, I'm used to building my own
> > packages with the exact build options I need [...]
> > What would you advise me to read?
> 
> Since no Debian Developers answered yet, i propose to read
>   https://www.debian.org/doc/manuals/maint-guide/
> and look for examples in
>   https://tracker.debian.org/pkg/$package_name
> and the "tools" and "box" icons to the left under "versioned links".
> Like
>   https://tracker.debian.org/media/packages/libi/libisoburn/rules-1.5.2-1
>   https://tracker.debian.org/media/packages/libi/libisoburn/control-1.5.2-1
> 
> 

Looks scary. In FreeBSD, you don't need a Developer's or Port
Maintainer's expertise to change a few build options and publish the
resulting package(s) in your intranet.

Still looking for a good tutorial or someone with personal experience.

-- 
Victor Sudakov,  VAS4-RIPE, VAS47-RIPN
2:5005/49@fidonet http://vas.tomsk.ru/

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

#228476

Hi,

i wrote:
> >   https://www.debian.org/doc/manuals/maint-guide/
> >   https://tracker.debian.org/media/packages/libi/libisoburn/rules-1.5.2-1
> > https://tracker.debian.org/media/packages/libi/libisoburn/control-1.5.2-1

Victor Sudakov wrote:
> Looks scary. In FreeBSD, you don't need a Developer's or Port
> Maintainer's expertise to change a few build options and publish the
> resulting package(s) in your intranet.

Yes. It is too complicated to package a well behaved upstream tarball
for Debian. I think this each time when i prepare the Debian packaging
after i released upstream.

So i also offer an all-in-one tarball of xorriso for self-compilers.
By a mere "./configure && make" it works on BSDs too. (But goes by the
name "GNU xorriso" which gives die-hard BSDers a blood pressure spike.)


> Still looking for a good tutorial or someone with personal experience.

Well, i showed what i use to get along with the inherited Debian packaging
preparations of my software. I doubt that i would have mastered the task
if i had to start from scratch. My thanks go to Eduard Bloch and George
Danchev who once packaged my stuff.

The packaging files are in a git of Debian. When i'm done with
preparations i ask my sponsor Dominique Dumont to produce and upload the
packages. See release cycles at:
  https://salsa.debian.org/optical-media-team/libisoburn/-/commits/master

Of course you will need no sponsor if you don't aim for the packages to
appear in the pools of Debian mirror servers.


Have a nice day :)

Thomas

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

#228466

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

On Wed, Nov 04, 2020 at 09:32:31PM +0700, Victor Sudakov wrote:
> Dear Colleagues,
> 
> As a person with the FreeBSD background, I'm used to building my own
> packages with the exact build options I need (those include exim, nginx,
> samba, clamav and many others). FreeBSD has a good infrastructure for
> this (ports tree, poudriere et al.)
> 
> Where can I learn to do a similar thing for Debian? I'd like to have my
> own package repository which:

If you're the kind of person who needs to get dirty fingers
while learning, pick a Debian package you care about (not a
very complex one) and download the source. Make a work
directory, cd there and download a source package (I'm using
hello, because it's small)

  tomas@trotzki:~$ mkdir work
  tomas@trotzki:~$ cd work
  tomas@trotzki:~/work$ apt-get source hello
  Reading package lists... Done
  Need to get 733 kB of source archives.
  [...]

Apt-get source will download the source package, unpack it,
and apply the Debian-specific patches. The result is now in
work/hello-2.10 (for buster). Look around; Debian specific
stuff (build machinery, patches, metadata) are in its
subdir debian.

You can install whatever is needed to build your package
(the so-called "build dependencies") by doing

  sudo apt-get build-dep hello

Then (in the package dir) you can do

  dpkg-buildpackage -uc -us

and watch the buildery do its magic :-)

There are several directions you can branch out from there.
Having the manual (pointed at by other nice folks in this
thread) handy is highly recommended. One very interesting
is how to decouple your build environment from your machine
environment (including building for other Debian versions,
cross building for other architectures, etc -> pbuilder,
sbuild, and my favourite, schroot). Or packaging something
new -> Debian New Maintainer's Guide) etc.

Enjoy
 - t

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

#228475

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

tomas@tuxteam.de wrote:
> > 
> > As a person with the FreeBSD background, I'm used to building my own
> > packages with the exact build options I need (those include exim, nginx,
> > samba, clamav and many others). FreeBSD has a good infrastructure for
> > this (ports tree, poudriere et al.)
> > 
> > Where can I learn to do a similar thing for Debian? I'd like to have my
> > own package repository which:
> 
> If you're the kind of person who needs to get dirty fingers
> while learning, pick a Debian package you care about (not a
> very complex one) and download the source. Make a work
> directory, cd there and download a source package (I'm using
> hello, because it's small)

[dd]

Thank you, it was very instructive!

The result of the described magic would be a .deb package, correct?

> 
> There are several directions you can branch out from there.
> Having the manual (pointed at by other nice folks in this
> thread) handy is highly recommended. One very interesting
> is how to decouple your build environment from your machine
> environment (including building for other Debian versions,
> cross building for other architectures, etc -> pbuilder,
> sbuild, and my favourite, schroot). Or packaging something
> new -> Debian New Maintainer's Guide) etc.

Next I would like to publish those tweaked and local packages in a local
repository in a corporate intranet, so that I could add this repository to
sources.list and its packages should override the standard Debian ones.

Maybe however, it is not such a good idea to publish for other systems a
package built outside a clean reference environment.

Actually I would like to get the better of the two worlds: the general good
quality and stability of Debian packages and - for selected packages only -
the flexibility of *BSD ports, or probably Gentoo(?).


-- 
Victor Sudakov,  VAS4-RIPE, VAS47-RIPN
2:5005/49@fidonet http://vas.tomsk.ru/

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

#228478

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

On Thu, Nov 05, 2020 at 12:39:34PM +0700, Victor Sudakov wrote:
> tomas@tuxteam.de wrote:
> > > 
> > > As a person with the FreeBSD background, I'm used to building my own
> > > packages with the exact build options I need (those include exim, nginx,
> > > samba, clamav and many others). FreeBSD has a good infrastructure for
> > > this (ports tree, poudriere et al.)
> > > 
> > > Where can I learn to do a similar thing for Debian? I'd like to have my
> > > own package repository which:
> > 
> > If you're the kind of person who needs to get dirty fingers

[...]

> Thank you, it was very instructive!

Glad you liked the rush through the swamp. I didn't tell you
about the crocs, though ;-)

> The result of the described magic would be a .deb package, correct?

Yes. It's deposited in the package dir's parent directory (in
my example that was "work").

> > There are several directions you can branch out from there.
[...]

> Next I would like to publish those tweaked and local packages in a local
> repository in a corporate intranet, so that I could add this repository to
> sources.list and its packages should override the standard Debian ones.

Ah, a new direction to branch into :-)

There are instructions on how to set up a Debian repository, e.g.
here [1].

> Maybe however, it is not such a good idea to publish for other systems a
> package built outside a clean reference environment.

If you keep your dependencies clean, things should work, mostly. If you
are building once-offs, you'll learn to cope with the rough edges.

Once you are dealing with many "customers", you should master [1] "clean
builds", either with sbuild, pbuilder or any other chroot-y or VM-y
scheme (I do use schroot to (cross-) build packages for a customer, for
example: I deliver one 386/Whezy version (really!) and another for Buster
on Raspberry Pi -- all from the comfort of my refurbished Thinkpad).

> Actually I would like to get the better of the two worlds: the general good
> quality and stability of Debian packages and - for selected packages only -
> the flexibility of *BSD ports, or probably Gentoo(?).

There are many moving parts, and they can be combined in many ways.
That's why I recommend starting with some minimal path (and accepting
some mistakes: for example just ignoring "clean builds" for the
start) knowing that you'll have to revisit your path once you know
more.

But there are many different ways to learn...

Cheers

[1] https://wiki.debian.org/DebianRepository#Set_up_and_maintain_a_repository
 - t

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

#228488

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

tomas@tuxteam.de wrote:

[dd]

> 
> > Next I would like to publish those tweaked and local packages in a local
> > repository in a corporate intranet, so that I could add this repository to
> > sources.list and its packages should override the standard Debian ones.
> 
> Ah, a new direction to branch into :-)
> 
> There are instructions on how to set up a Debian repository, e.g.
> here [1].

Maybe I'm looking in the completely wrong direction? Maybe it would be
easier to install such "special" packages with Docker or Snap or
something similar? Would this eliminate the problem of dependencies and
clean builds? 

-- 
Victor Sudakov,  VAS4-RIPE, VAS47-RIPN
2:5005/49@fidonet http://vas.tomsk.ru/

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web