dailydebs-team team mailing list archive

[Harald Sitter <apachelogger@xxxxxxxxxx>]

On Tue, Aug 11, 2009 at 10:48 AM, James Westby<jw+debian@xxxxxxxxxxxxxxx> wrote:
> Harald Sitter wrote:
>> On Tue, Aug 4, 2009 at 1:28 PM, James Westby<jw+debian@xxxxxxxxxxxxxxx> wrote:
>>> Hi all,
>>>
>>> I'm interested in your opinions on what makes a good daily package.
>>> We know what makes a good package, but there are extra requirements
>>> for daily builds, which I am mainly guessing revolve around maintenance,
>>> but may include things in the package.
>>
>> Some things that came to my mind
>
> Thanks for the ideas.
>
>> * low maintenance
>
> This is more something for the maintainer than the users?

Kind-off, although it indirectly affects the user anyway. As I see it
there are two kinds of low maintenance. By design and by
implementation. Project Neon uses monolithic packaging (all goes into
one package), hence it tries to archive low maintenance by design, if
it would use stuff like list-missing/fail-missing with a more complex
packaging it would try to archive it by implementation. In either
case, low maintenance means mostly to reduce the probability of
problems, the less problems, the better the user experience ;-)

>> * co-installable with stock archive packages
>
> This is interesting, I don't do this. I can see the value, but it's not
> always easy, and makes it harder to share packaging with the
> distribution packages.

Depends a lot of the implementation, for KDE it would be pretty easy,
since the Kubuntu packaging is using CDBS for core KDE, one would just
need to abstract it so that the installation paths are changed and
possibly hook into the actually package building to attach some string
to the package name (e.g. make kdebase kdebase-ng). So, technically it
wouldn't be any more work than maintaining a non-co-installable
packaging which allows sharing with the distribution. The reason
Project Neon doesn't use this approach however is that low maintenance
by design requires less maintainer changes than by implementation (one
would still need to add new packages for new applications etc.)

>> * sandboxed configuration data
>
> This can be a pain as well as a safety feature can't it?

Depends a lot on upstream, for KDE it is pretty easy since its
internal structure is very dynamic (as a matter of fact you can
manipulate everything necessary for sandboxing the configuration via
env vars). While this adds to safety it also makes it easier for the
user to not break a working system (also in connection with
co-installability).

>> * should never ever break ;-)
>
> Of course ;-)
>
>> * upstream changelog data should be easily accessible
>
> Why is this?

A friend of mine recently mentioned that in some recent chrome
snapshot for Mac there was no changelog available, which made him,
being an interested user and everything, wonder what was changed
(especially since he can't checkout all the new fancy stuff). Also,
since the packaging changelog doesn't usually contain any valuable
information it would maybe be best to fill it with upstream data
instead.

>> * in case of a stack a partial break should not break the whole stack
>
> Isn't this virtually impossible?

Depends on the kind of break. FTBFS related breaks can be avoided by
using a staging PPA and uploading stuff one-by-one (which is necessary
anyway), and only publish to a stable PPA if the stack built
successfully. ABI breaks will be prevented by the one-by-one upload.
API breaks will result in a FTBFS anyway. So I think the only
remaining cause of break (that can be influenced) is a file conflict
in the packaging which I'll describe later.

>> * provide debug symbols
>
> +1. I'd like it if it was possible to get something like apport
> retracing for these packages, but LP doesn't allow us to know where the
> bugs should go yet, which makes it difficult. Including debug symbols
> lessens this need, and may be the better solution anyway.

I think in either case the debug symbols should be available since
that way a user who knows what he is doing can file bugs directly with
upstream, without having to pass it through LP using apport.

>> * not too big in size
>
> Due to the load of updating every day?

Aye, ultimately we would find a way to decrease the overall size of
package updates all together (see what google chrome does). But for
the time being I would usually go with the following: don't force
debug symbols into a binary package (in case of monolithic design) and
use LZMA compression. Especially the latter can decrease the size of
packages a lot (about 50% for KDE dbg packages). While it requires
more resources at compression time it is almost equal to GZIP at
decompression so for daily builds it probably is most recommendable to
use LZMA.

>> * file moves across packages of a stack should not make those packages
>> cause file conflicts
>
> Is this to do with the way that you construct the packaging, or is it
> watching out for these cases and acting on them?

Both I suppose. Some KDE core packages don't split to application
level (multiple applications and libraries make up a KDE core package,
so one src package might have up to 30 individual packages), so
instead of maintaining 30 packages only important apps get split out
and the rest only gets diverted into generic -data -libs and -bin
packages, hence it is easier to prevent conflicts (due to the reduce
amount of packages to watch).
It also is a matter of watching out for these. They can be
auto-detected using file list comparisions (again, using a two PPA
setup with staging and stable, you would compare staging to stable and
check if files were moved across packages, then fail and alert
maintainer).
For monolithic packaging it can actually be full automated, since a
script just needs to add the appropriate replaces/conflicts...


regards,
Harald