Package: debian-policy
Severity: wishlist
Proposal:
This is a proposal to add information about a package's build environment
to the "changes" file that accompanies the upload of each package. The
build environment information contains the versions of packages used to
build the given package. The
On Thu, Mar 14, 2002 at 11:08:42PM -0800, Randolph Chung wrote:
> 2. Ideally one might want to recursively list all the dependents of build-
> dependencies too, but that is probably too expensive to compute.
On my Pentium 166MHz, the following command took about 10s (real) to
run, with devscripts
Hi,
First of all, I'm not sure if this is the correct mailing list to post
this question, if not, please tell me what's the correct one.
Follows the question:
I work in a software house and we always publish our software using deb
packages. We have a little server configured with a Packages.gz,
> > 2. Ideally one might want to recursively list all the dependents of build-
> > dependencies too, but that is probably too expensive to compute.
> On my Pentium 166MHz, the following command took about 10s (real) to
> run, with devscripts (>= 2.6.90) installed:
Thanks, that was good to know.
o
On Fri, Mar 15, 2002 at 07:14:44AM -0800, Randolph Chung wrote:
> > > 2. Ideally one might want to recursively list all the dependents of build-
> > > dependencies too, but that is probably too expensive to compute.
> > On my Pentium 166MHz, the following command took about 10s (real) to
> > run, w
On Fri, Mar 15, 2002 at 10:20:28AM -0300, Daniel Ruoso wrote:
> I want to publish the software in different stages (unstable, testing,
> frozen and stable, just like debian itself), because I will have
> machines testing each distribution.
We no longer have a "frozen".
> Finally, the question is.
>>"Daniel" == Daniel Ruoso <[EMAIL PROTECTED]> writes:
Daniel> I want to publish the software in different stages (unstable, testing,
Daniel> frozen and stable, just like debian itself), because I will have
Daniel> machines testing each distribution.
Daniel> Finally, the question is...
Dani
>>"Randolph" == Randolph Chung <[EMAIL PROTECTED]> writes:
Randolph> Proposal: This is a proposal to add information about a
Randolph> package's build environment to the "changes" file that
Randolph> accompanies the upload of each package. The build
Randolph> environment information contains
Daniel Ruoso <[EMAIL PROTECTED]> writes:
> I want to publish the software in different stages (unstable, testing,
> frozen and stable, just like debian itself), because I will have
> machines testing each distribution.
>
> Finally, the question is...
> What's the better strategy to publish packag
Randolph Chung <[EMAIL PROTECTED]> cum veritate scripsit:
> one problem is that some packages have build-dependency chains that
> when resolved completely are very deep, and sometimes contains dependency
> cycles. One could argue that these are bugs, but they seem difficult to fix
> in some cases
> And the bit
> about standards version is a red herring, really: packages are
> supposed to be current with policy (which is why policy froze) -- it
> is just that stable releases have packages that conform to policy as
> it existed then. Packages in Sid need to be current (can't claim
> anci
Processing commands for [EMAIL PROTECTED]:
> severity 138409 wishlist
Bug#138409: [PROPOSAL] Add build environment data to .changes files
Severity set to `wishlist'.
> reassign 138409 dpkg
Bug#138409: [PROPOSAL] Add build environment data to .changes files
Bug reassigned from package `debian-poli
>>"Randolph" == Randolph Chung <[EMAIL PROTECTED]> writes:
Randolph> sure eventually all packages will move to the new scheme,
Randolph> and everything will be happy. i'm not suggesting anything
Randolph> more or less.
Then it can't be made mandatory from the word go, if every
single
On Mar 15, Thomas Bushnell, BSG wrote:
> Daniel Ruoso <[EMAIL PROTECTED]> writes:
>
> > I want to publish the software in different stages (unstable, testing,
> > frozen and stable, just like debian itself), because I will have
> > machines testing each distribution.
> >
> > Finally, the question
14 matches
Mail list logo
