|
Home > Archive > Debian Developers > March 2004 > [custom] Generalizing building scripts of meta packages
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
[custom] Generalizing building scripts of meta packages
|
|
| Andreas Tille 2004-03-24, 4:34 am |
| Hi,
I'm currently working on the move from the former packaging method of
Debian-Med meta packages to the Debian-Edu scheme which builds all meta
packages from one source. I'd like to uses as much as possible common
code which will end up in a cdd-dev package which might be used by all
Custom Debian Distributions. (I'll check this into alioth once it is up and
running again.)
The first changes I did are regarding gen-control script of debian-edu
Changes to gen-control
- Use /etc/cdd/sources.list as default sources.list
If "-s <dist>" is specified /etc/cdd/sources.list.<dist>
is used. Otherwise the argument to option -s is used as
sources.list.
- /tmp/cdd-apt is used as $aptdir
The rationale behind this is to keep the cache stored on
building machine even after cleaning up build directory.
- The file debian/control.stub is searched for an entry
"^Package: <cdd>". If this is found it is used as prefix
for the packages, so the builded packages are named as
<cdd>-{task1,task2,task3,...}. The default cdd remains
"education-".
- If there is a common directory a <cdd>-common package is
builded as well. In this case a file common/control
must be provided.
This changes would not require any change in the debian-edu packaging stuff.
I just want to discuss the fact that Building meta packages might depend
from the configuration of cdd-dev (*if* /etc/cdd/sources.list is used). The
rationale behind this was that when *developing* the packages on different
machines (perhaps offline with a local mirror) you can work nicely and
meta packages are normally architecture "all" - thus no problems with
auto builders are to be expected. Moreover you are always free to provide
a source.list file for your *final* build of the package while using the
"-s" option as before.
What is your opinion about uding /tmp/cdd-apt to keep the apt-cache?
What do you think about building debian/control for every build instead of
calling gen-control only once and continue with the created debian/control file.
Kind regards
Andreas.
PS: If you want to get rid of [custom] tagged mails in debian-devel just
write a comment to #237017.
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Free Ekanayaka 2004-03-28, 8:35 pm |
| >>>>> On Wed, 24 Mar 2004 10:04:14 +0100 (CET), Andreas Tille <tillea@rki.de> said:
Andreas> Hi, I'm currently working on the move from the former
Andreas> packaging method of Debian-Med meta packages to the
Andreas> Debian-Edu scheme which builds all meta packages from one
Andreas> source. I'd like to uses as much as possible common code
Andreas> which will end up in a cdd-dev package which might be
Andreas> used by all Custom Debian Distributions. (I'll check
Andreas> this into alioth once it is up and running again.)
I think this is a good idea. What are you planning to include in the
cdd-dev package exactly? A template for a custom source meta-package?
Andreas> The first changes I did are regarding gen-control script
Andreas> of debian-edu
Andreas> Changes to gen-control - Use /etc/cdd/sources.list as
Andreas> default sources.list If "-s <dist>" is specified
Andreas> /etc/cdd/sources.list.<dist> is used. Otherwise the
Andreas> argument to option -s is used as sources.list. -
Ok. I admit I do not fully understand the arguments on this issue you
state below, but, as long a custom sources.list can be specified via
the -s option, everything is fine for me.
Andreas> /tmp/cdd-apt is used as $aptdir The rationale behind this
Andreas> is to keep the cache stored on building machine even
Andreas> after cleaning up build directory.
Ok.
Andreas>- The file
Andreas> debian/control.stub is searched for an entry "^Package:
Andreas> <cdd>". If this is found it is used as prefix for the
Andreas> packages, so the builded packages are named as
Andreas> <cdd>-{task1,task2,task3,...}. The default cdd remains
Andreas> "education-".
Good. Having one single point to edit when customising the template
would be great.
Andreas> - If there is a common directory a
Andreas> <cdd>-common package is builded as well. In this case a
Andreas> file common/control must be provided.
What is the package <cdd>-common supposed to contain exactly? Specific
files and data for the CDD?
Andreas> This changes would not require any change in the
Andreas> debian-edu packaging stuff. I just want to discuss the
Andreas> fact that Building meta packages might depend from the
Andreas> configuration of cdd-dev (*if* /etc/cdd/sources.list is
Andreas> used). The rationale behind this was that when
Andreas> *developing* the packages on different machines (perhaps
Andreas> offline with a local mirror) you can work nicely and meta
Andreas> packages are normally architecture "all" - thus no
Andreas> problems with auto builders are to be expected. Moreover
Andreas> you are always free to provide a source.list file for
Andreas> your *final* build of the package while using the "-s"
Andreas> option as before.
Andreas> What is your opinion about uding /tmp/cdd-apt to keep the
Andreas> apt-cache?
Fine for me.
Andreas> What do you think about building debian/control for every
Andreas> build instead of calling gen-control only once and
Andreas> continue with the created debian/control file.
Yes, I think regenerating the control file at every build is a better
choice.
Cheers,
Free Ekanayaka
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Andreas Tille 2004-03-29, 12:35 am |
| On Mon, 29 Mar 2004, Free Ekanayaka wrote:
[I think I should foreward this to debian-devel even if I quote small parts
of your private mails...]
> I think this is a good idea. What are you planning to include in the
> cdd-dev package exactly? A template for a custom source meta-package?
http://cvs.alioth.debian.org/cgi-bi...on/?cvsroot=cdd
Just try to get an Alioth account and I'll add you to the project.
> What is the package <cdd>-common supposed to contain exactly? Specific
> files and data for the CDD?
The (current and future) med-common has debconf templates for administration
of med - users, a simple script which just showas some information which each
other med - package is symlinking to. This enables auto-apt usage like this:
~ auto-apt -x -y run
$ med-bio
...
Med-bio and its dependencies will be installed automagically which
is kind of cool when demonstrating it in workshops or at a exhibition
booth, but not really honest stuff. So the main thing is the user
administration currently but I'm pretty sure that there will be additional
uses of a common package in the future.
> Yes, I think regenerating the control file at every build is a better
> choice.
OK. In any case you are free to do it once by calling cdd-gen-control
outside of your debian/rules file.
Kind regards
Andreas.
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Free Ekanayaka 2004-03-29, 4:38 am |
| >>>>> On Mon, 29 Mar 2004 07:28:14 +0200 (CEST), Andreas Tille <tillea@rki.de> said:
[color=darkred]
Andreas> The (current and future) med-common has debconf templates
Andreas> for administration of med - users, a simple script which
Andreas> just showas some information which each other med -
Andreas> package is symlinking to. This enables auto-apt usage
Andreas> like this:
Andreas> ~ auto-apt -x -y run $ med-bio ...
Andreas> Med-bio and its dependencies will be installed
Andreas> automagically which is kind of cool when demonstrating it
Andreas> in workshops or at a exhibition booth, but not really
Andreas> honest stuff. So the main thing is the user
Andreas> administration currently but I'm pretty sure that there
Andreas> will be additional uses of a common package in the
Andreas> future.
Nice. I think this shows that the possibility to have a <cdd>-common
package which is not auto-generated from the a tasks/* file is a good
thing, and everybody is free to use it in the way he/she prefers.
On the other hand, speaking about possible debconf questions and
automatic system configuration, I like very much the approach of the
debian-edu-config/debian-edu-install packages. That means having a
separate source package (after all this is not a task package), which
holds a pre-canned set of debconf values to inject and which manages
everything else via cfengine.
My only concern is that I'd move the debconf part of
debian-edu-install into debian-edu-config. This way everything related
with configuration is managed in a single source package which I'd
call "<cdd>-config", while I'd call the source package for the
<cdd>-<task> packages "<cdd>-tasks", and a possible installation level
package "<cdd>-install".
[color=darkred]
Andreas> OK. In any case you are free to do it once by calling
Andreas> cdd-gen-control outside of your debian/rules file.
Fine.
Cheers,
Free Ekanayaka
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Andreas Tille 2004-03-29, 8:41 am |
| On Mon, 29 Mar 2004, Free Ekanayaka wrote:
> Nice. I think this shows that the possibility to have a <cdd>-common
> package which is not auto-generated from the a tasks/* file is a good
> thing, and everybody is free to use it in the way he/she prefers.
>
> On the other hand, speaking about possible debconf questions and
> automatic system configuration, I like very much the approach of the
> debian-edu-config/debian-edu-install packages. That means having a
> separate source package (after all this is not a task package), which
> holds a pre-canned set of debconf values to inject and which manages
> everything else via cfengine.
Well, the reason is that I did not had the time to check this package
and just tied to implement all stuff I need into a similiar build system.
Just regard all I have done as a "request for comment" work and feel
free to send patches.
[Damn Alioth seems to be down once again :-((]
> My only concern is that I'd move the debconf part of
> debian-edu-install into debian-edu-config. This way everything related
> with configuration is managed in a single source package which I'd
> call "<cdd>-config", while I'd call the source package for the
> <cdd>-<task> packages "<cdd>-tasks", and a possible installation level
> package "<cdd>-install".
May be it would make sense to move <cdd>-common to a separate source
package (I do not care about the name here - but the user menu configuration
and auto-apt - helper, etc.)
Kind regards
Andreas.
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
|
|
|
|
|