Re: Pre-BOF CDD ideas
- To: Custom Debian Distributions <email@example.com>
- Subject: Re: Pre-BOF CDD ideas
- From: Free Ekanayaka <firstname.lastname@example.org>
- Date: Wed, 02 Jun 2004 11:31:45 +0200
- Message-id: <email@example.com>
- In-reply-to: <20040530152614.GA2671@answer.42.it> (Cosimo Alfarano's message of "Sun, 30 May 2004 12:26:14 -0300")
- References: <20040530030600.GA10823@answer.42.it> <Pine.LNX.firstname.lastname@example.org> <20040530152614.GA2671@answer.42.it>
>>>>> On Sun, 30 May 2004 12:26:14 -0300, Cosimo Alfarano <email@example.com> said:
Cosimo> The main problem of this is that lots of people working on
Cosimo> CDDs are not DD, so it leads to problems uploading
Cosimo> packages, and such an infrastrcuture would work only if
Cosimo> CDD are able to use official Debian packages and push
Cosimo> patches to maintainers, without having to fork.
I fit perfectly in this situation. I'm not (yet) a DD (my application
is hanging somewhere on Debian servers..), but I have lots of things
related to aGNUla/DeMuDi that I'd like to upload and maintain. I set
up my own repository at http://apt.agnula.org/demudi/, but I'd like to
In Valencia we agreed that this list should act as link between
unofficial CDD developers and Debian, so if the DDs on debian-custom
could help non-DDs uploading their packages that would be great.
>> package-xy. So I see no big practical use for this package
>> flavours because the above seems to be stupid and needs more
>> maintenance than trying to go with sane configuration
Cosimo> I'm not speaking about configuration issues, but about
Cosimo> patches needed and now wanted to be applied, for example.
Cosimo> If the package will be uploaded in an external repository
Cosimo> it breaks completly the idea of a virtualized
Cosimo> testing/stable distro per CDD (and the 100% Debian idea).
IMHO having different flavours of the same package should be
considered an extreme solution, when no other alternative is
available. As a general rule I think complexity should be kept at the
minimum possible value, and having 2 packages for the same software
means that you have to double the work. Just think when new upstream
source comes out.
I most cases I think that a patch can be included in the original
package without hurt, by introducing a command line flag
(e.g. /usr/bin/myprog --my-patch) or similar switches.