Future development of debian-edu packages (Was: Processing of debian-edu_0.828_i386.changes)
[debian-custom in CC because the main part of this mail which starts
at item 3. below is about general CDD development issues and thus
this part should be discussed on the debian-custom list.]
On Tue, 11 Mar 2008, Archive Administrator wrote:
debian-edu_0.828_i386.changes uploaded successfully to localhost
As you see the fix for the problem that continuosely caused bug
reports about missing files / needs network connection when building
is uploaded. The fix was accomplished by the approach suggested in [1].
As agreed yesterday in the meeting I suggest some points for future
development. Here they come (in lower to higher importance order):
1. Lintian:
$ lintian -i education-desktop-other_0.828_i386.deb
E: education-desktop-other: depends-on-x-metapackage recommends: xorg
N:
N: Packages that are not themselves metapackages must not depend on X
N: Window System metapackages.
N:
N: The metapackages xorg, xorg-dev, x-window-system, x-window-system-dev,
N: and x-window-system-core exist only for the benefit of users and
N: dependencies for other metapackages and should not be used in regular
N: package dependencies.
N:
--> Whoever inserted this dependency should fix this.
2. Norwegian comments in tasks/* files
--> Whoever wrote these comments please either translate or
remove them. I will remove them myself for the next+1
release in case they would stay there untouched with the
rationale that if nobody cares about them _now_ they are
not important enough to stay there.
3. Currently the packages are built arch=any based on the available
package list for i386. Because this might leed to Recommends of
packages that are missing on some Architectures and Lenny
Release goals[2] say: "No unmet recommends relations inside main"
we have to change this. In the (unofficial) meeting at March 3rd
I proposed the following to solve this for long term:
For the web tools I wrote to produce the tasks pages I developed
a Python module that is able to parse RFC822 files (debian/control,
Packages, etc.). Using this module it is easy to read any
architecture Packages file and create respective control files
into debian/control.d/control.<arch> or whatever name might be
apropriate (speak up now or be silent for ever for a better
naming scheme).
In the package source only a skeleton debian/control file should
be stored that will definitely not lead to any package just make
dpkg-buildpackage happy to start the build process once debian/rules
takes over the work the arch is detected and the correct debian/control
will be either symlinked or copied. The same procedure will be done
with the tasksel.desc files (except having the skeleton in the
beginning because it is not explicitely required).
What we need as input to get all these files created using the make
dist target is a path to the packages files (currently the available
packages are found via the sources.list files). We need a hostname
and a base directory where the debian files are stored at this host.
Then we need the architectures of the target distribution because
I'm not fully sure whether we can obtain the list of available
arches under host/dir/dist automatically. The arches are known for
plain Debian, but there are other SkoleLinux releases out there
and we should enable this as well. So some kind of configuration
file is needed that contains this kind of information. I guess we will
not get a new architecture every other day so it might be maintainable
for the future.
Alternatively we could just use a list of all Debian architectures.
If no such Packages-arch file is found no control file will be created.
This is most probably the simples solution.
(In IRC H01ger said the hard coded list of archs is OK, I'm undecided
yet. What location / name would you suggest for such a list?)
A completely different approach as alternative to the preparation
of control files for all architectures inside the source package
was suggested by vagrantc who suggested using
/var/lib/apt/lists/*Packages from the buildd at build-time but
admitted that build in an un-clean chroot might break things.
Thinking twice about this I consider the idea on one hand attractive
because it is less effort, but my initial argument that you might
end up with different packages if you build them at different points
in time from the same source. This effect is not as drastical as
vagrantc was afraid of because we do not store package versions
but only whether a package is available or not. But it might make
a difference in the dependency list if you build the package this
week or next week if some packages were added to or removed from
Debian inbetween - expecially if we think of cases like current
mips backlog. It might perfectly be that if we build
debian-edu_mips packages based on todays /var/lib/apt/lists/*Packages
the list of dependency will be really different next week in case
the backlog would be reduced.
However, if you build the same source package at different points
in time you can always get a different dependency list (think of
different library versions when using ${shlibs:Depends}, etc.) and
thus the question is whether my argument is really valid for what
we want to approach. My first proposal with debian/control.d
files would reflect the package pool status at the point in time
the meta package source was built using "make dist".
4. The implementation of the plan above technically is a rewrite
of cdd-gen-control (which is just a tweaked gen-control of former
debian-edu packages). The problem I currently have is that I
need some more detailed information about how gen-control is
handling some keys that were invented by debian-edu in the
tasks files without any documentation. I asked for clarification
in [3] but got no response. I more or less repeat / enhance
my previous question:
'Architecture': meaning is clear, but do we really need this -
I guess having the same architecture for every
metapackage builded by the same source package
(either 'all' or 'any') should be OK, right.
Thinking twice about it: Probably cdd-dev should
not build arch=all meta packages but force
any following the plan above if we would like
to meet the Lenny release goal.
'Avoid', 'Ignore': meaning not fully clear, especially what
is the difference?
'Leaf': meaning unclear
'NeedConfig': meaning unclear
'Note': What's the difference to the 'Why' key that is used
as 'just another comment'
'Section': meaning is clear, but I wonder whether it makes
sense to sort different meta packages in different
sections. I'm not against it, but I would like to
hear some hard reasons
Congratulations - you reached the end of this mail. I would be
really happy if I would not have consumed all your spare time and
you are able to comment on this. :)
Kind regards
Andreas.
[1] http://lists.debian.org/debian-edu/2008/02/msg00242.html
[2] http://release.debian.org/lenny/goals.txt
[3] http://lists.debian.org/debian-edu/2008/03/msg00025.html
--
http://fam-tille.de
Reply to: