[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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:   Packages that are not themselves metapackages must not depend on X
    N:   Window System metapackages.
    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.

    --> 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


[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

Reply to: