Steve Langasek wrote:
> The installer team are consulted on the
> question of which packages should be made available as udebs, but for shared
> libraries the maintenance of the udeb definitely lies with the library
> maintainer, not the installer team. So it makes pe
Russ Allbery wrote:
> I vote for just calling them "udebs" instead of "micro binary packages."
> The latter sounds more formal, but I don't think anyone calls them that in
> practice, so it may be confusing. Perhaps:
>
> udebs (stripped-down binary packages used by the Debian Installer) are
>
On Sun, Jan 13, 2013 at 08:35:36AM -0800, Jonathan Nieder wrote:
> Bill Allombert wrote:
> > In that case there could be a udeb subpolicy document maintained by the
> > d-i team that policy would refer to.
> Yeah, that would be fine with me, even though I still don't see the
> point.
> Is there
Charles Plessy writes:
> How about the following change to the first paragraph of section 1.1 ?
> This manual describes the policy requirements for the Debian
> distribution. This includes the structure and
> contents of the Debian archive and several design issues
Le Sun, Jan 13, 2013 at 08:35:36AM -0800, Jonathan Nieder a écrit :
>
> What I am concerned about is that the next release of policy should not
> include wording that requires people to make a decision between ignoring what
> policy says and filing RC bugs about, e.g., udebs not including changelo
Russ Allbery (13/01/2013):
> It makes sense to me to add such a statement now and then circle
> back to possibly document the details of udebs (and, if so, remove
> that statement) at a later date when the d-i team has more time.
Definitely.
Mraw,
KiBi.
signature.asc
Description: Digital signa
Jonathan Nieder writes:
> Yet I'm getting a lot of resistance to the suggestion. Why? What am I
> missing?
I think it's perfectly reasonble, even quite valuable, to include a clear
statement in Policy that it doesn't cover udebs and they have their own
guidelines. I didn't realize there was a
On Sun, Jan 13, 2013 at 08:35:36AM -0800, Jonathan Nieder wrote:
> Bill Allombert wrote:
>
> > In that case there could be a udeb subpolicy document maintained by the
> > d-i team that policy would refer to.
>
> Yeah, that would be fine with me, even though I still don't see the
> point.
>
> Is
Bill Allombert wrote:
> In that case there could be a udeb subpolicy document maintained by the
> d-i team that policy would refer to.
Yeah, that would be fine with me, even though I still don't see the
point.
Is there a git subpolicy describing how git is packaged? A gnome
subpolicy about gno
On Sun, Jan 13, 2013 at 12:44:33AM -0800, Jonathan Nieder wrote:
> Charles Plessy wrote:
>
> > If you think that it is necessary to obtain the agreement of the d-i team to
> > mention the udebs in #697433, please go ahead, but on my side, I do not
> > think
> > that there is a problem here.
>
>
Charles Plessy (13/01/2013):
> I think that describing the udebs would fit with that goal.
For the record: no objection.
> This said, it can not be done without the active participation of
> the d-i team, which I do not want to bother now.
ACK.
Mraw,
KiBi.
signature.asc
Description: Digital
Charles Plessy wrote:
> If you think that it is necessary to obtain the agreement of the d-i team to
> mention the udebs in #697433, please go ahead, but on my side, I do not think
> that there is a problem here.
I guess I'm completely failing to communicate.
udebs are already documented very cl
Le Sun, Jan 13, 2013 at 12:13:04AM -0800, Jonathan Nieder a écrit :
>
> I don't think policy should define how udebs work. The entire
> installer is maintained by the d-i team, and it seems best if they
> have freedom to change how it works without changing any documentation
> maintained by other
Charles Plessy wrote:
> actually the only section of the Policy that currently contains the string
> 'udeb' is 8.6.4.2 about the shlibs system (plus some occurences in
> introductory
> parts earlier in the chapter 8). No bug in our list mention "udeb" either.
>
> I therefore am filing this new b
14 matches
Mail list logo