On Tue, 18 Jul 2000, Wichert Akkerman wrote:
> Previously Jason Gunthorpe wrote:
> > *shrug* you'll be seeing that soon enough in other forms, doesn't trouble
> > me much as long as the functionality is very tertiary.
> Can you elaborate on that? You seem to be doing what you are accusing
> me
On Mon, 17 Jul 2000, Clint Adams wrote:
> > I could definately see where you do 'dpkg-buildpackage -O debian' or
> > 'dpkg-buildpackage -O corel'
>
> What? Why would anyone want a proliferation of packages that are identical
> except for one control field? If Plagiarism GNU+Linux wants to take
On Mon, Jul 17, 2000 at 05:59:02PM -0600, Jason Gunthorpe wrote:
>
> On Tue, 18 Jul 2000, Wichert Akkerman wrote:
>
> > The bugs-tag(s) tell you who is responsible for a package and where you
> > can file bugs. Even if Corel or Stormix ship a Debian package, it is
> > still *our* package and we a
Previously Jason Gunthorpe wrote:
> *shrug* you'll be seeing that soon enough in other forms, doesn't trouble
> me much as long as the functionality is very tertiary.
Can you elaborate on that? You seem to be doing what you are accusing
me of and adding things like Sources and Release without disc
> Who said anything about that option only affecting the fields Wichert
> mentioned?
>
> Think about debian/rules that look for what origin they are building for, and
> take appropriate action.
If you're going to use debian/rules to do conditional building for multiple
origins you may as well con
On Tue, 18 Jul 2000, Wichert Akkerman wrote:
> Previously Jason Gunthorpe wrote:
> > dpkg can access it just fine in all the contexts where a Release file
> > can exist (being called from APT basically), the only problem I see is
> > that hand installed debs would lack this information - a much s
On Mon, Jul 17, 2000 at 02:33:34PM +0200, Adrian Bunk <[EMAIL PROTECTED]> was
heard to say:
> Successor-Of:
> As far as I know, a package isn't upgraded if it's name has changed
> (e.g. fvwm2 -> fvwm or cdgrab -> abcde). This field is meant for this case
> (the new package is "Successor-Of" the ol
Previously Jason Gunthorpe wrote:
> dpkg can access it just fine in all the contexts where a Release file
> can exist (being called from APT basically), the only problem I see is
> that hand installed debs would lack this information - a much smaller
> price to pay than having a proliferation of 'n
Adrian Bunk <[EMAIL PROTECTED]> writes:
> On Sun, 16 Jul 2000, Wichert Akkerman wrote:
>
> > Package: packaging-manual
> >
> > I'm adding three new fields to debian/control:
> >...
>
> Sorry if I do perhaps address the wrong people, but I would like to
> propose two other fields (there might be
>>"Wichert" == Wichert Akkerman <[EMAIL PROTECTED]> writes:
Wichert> I'm adding three new fields to debian/control: All of these
Wichert> fields have to be in the general section of the
Wichert> control-file.
What, no rationale? No discussion of whether this is the best
way to do thin
>>"Jim" == Jim Lynch <[EMAIL PROTECTED]> writes:
>> Where was the consensus reached, saying this should be done? I'm willing to
>> read -archives about it, if someone tells me the list, and the date range.
Jim> He maintains dpkg... that's not enough?
Umm, I have problems with any deve
On Mon, 17 Jul 2000, Wichert Akkerman wrote:
> > > dpkg has no access to the Release file.
> >
> > Duh.
> >
> > Why don't you try to fix that instead.
>
> No, the Release file is a wrong design, dpkg *cannot* access it.
dpkg can access it just fine in all the contexts where a Release file
can
> > Well, that's not necessarily true. The Origin field could just
> > provide a *way* to get the bug-submission data you need. I mean:
>
> Which is entirely silly considering that I frequently make bugreports
> while I'm not online and batch-send them when I dialin. Your scheme
> would make tha
Previously Itai Zukerman wrote:
> Well, that's not necessarily true. The Origin field could just
> provide a *way* to get the bug-submission data you need. I mean:
Which is entirely silly considering that I frequently make bugreports
while I'm not online and batch-send them when I dialin. Your s
Previously Jason Gunthorpe wrote:
> > dpkg has no access to the Release file.
>
> Duh.
>
> Why don't you try to fix that instead.
No, the Release file is a wrong design, dpkg *cannot* access it.
Wichert.
--
_
/ Generally unint
On Mon, 17 Jul 2000, Clint Adams wrote:
> > I could definately see where you do 'dpkg-buildpackage -O debian' or
> > 'dpkg-buildpackage -O corel'
>
> What? Why would anyone want a proliferation of packages that are identical
> except for one control field? If Plagiarism GNU+Linux wants to take
> I could definately see where you do 'dpkg-buildpackage -O debian' or
> 'dpkg-buildpackage -O corel'
What? Why would anyone want a proliferation of packages that are identical
except for one control field? If Plagiarism GNU+Linux wants to take my
package, modify nothing except the control file,
Great, I suggest moving this discussion to debian-devel and you post
it to the other two lists but not -devel :)
Previously Chris Lawrence wrote:
> - A debbugs BTS has more than one submission address (maintonly,
> submit, quiet). Perhaps the URL should be a pseudo-URL, like
> mailto:[EMAIL PROT
On 17 Jul 2000, Itai Zukerman wrote:
> > No, that's silly. That would mean all bugreporting tools would need
> > a comprehensive list of all Origins out there, which is not reasonable.
> Well, that's not necessarily true. The Origin field could just
> provide a *way* to get the bug-submission
On Mon, 17 Jul 2000, Chris Lawrence wrote:
> As the reportbug maintainer, let me make a few suggestions:
>
> - A debbugs BTS has more than one submission address (maintonly,
> submit, quiet). Perhaps the URL should be a pseudo-URL, like
> mailto:[EMAIL PROTECTED]
That doesn't strike me as very
> > That does not make sense to me. I think the program that reports bugs
> > against a package should know from the Origin how to do that so if we
> > change to another BTS we would only need to change that program.
>
> No, that's silly. That would mean all bugreporting tools would need
> a comp
On Mon, 17 Jul 2000, Jim Lynch wrote:
> > and should be merged into a single field
>
> I am not convinced of this.
Well, provide a strong reason for having two fields when they can always
be merged into one. Hint: everything else that uses RFC-822 records uses 1
field were possible, you don't s
On Mon, 17 Jul 2000, Wichert Akkerman wrote:
> Previously Jason Gunthorpe wrote:
> > Consider, if Corel distributes Debian + Their Junk they will want to get
> > bug reports for the whole thing not just their packages. Having them
> > rebuild all our stuff just to change those fields is not entir
(Shall we move this discussion to debian-devel?)
Previously Torsten Landschoff wrote:
> That does not make sense to me. I think the program that reports bugs
> against a package should know from the Origin how to do that so if we
> change to another BTS we would only need to change that program.
On Jul 16, Wichert Akkerman wrote:
> I'm adding three new fields to debian/control:
>
> * Origin
> This lists the origin of a package. For all Debian packages this should
> be `Debian'.
> * Submit-Bugs-To
> An mailto URL to which bugs should be submitted. (It's a URL so
> we can support
Previously Jason Gunthorpe wrote:
> Consider, if Corel distributes Debian + Their Junk they will want to get
> bug reports for the whole thing not just their packages. Having them
> rebuild all our stuff just to change those fields is not entirely good for
> them - or us.
So they ship a bugreporti
Previously Adam Heath wrote:
> Is this created in debian/control by the maintainer, or should it be inserted
> at package build time by an automated tool? Indeed, couldn't all fields be
> inserted at package build time?
Right now in debian/control. I've been thinking of making a configuration
fil
Hi,
> Date:17 Jul 2000 10:17:55 EDT
> To: debian-devel@lists.debian.org
> From:Itai Zukerman <[EMAIL PROTECTED]>
> Subject: Re: new fields in debian/control
>
> > > * Origin
> > > This lists the origin of a package. For all Debian packages this should
> > > be `Debian'.
>
> Wil
Hi Torsten!
On Mon, 17 Jul 2000, Torsten Landschoff wrote:
> On Sun, Jul 16, 2000 at 01:32:26PM -0400, Wichert Akkerman wrote:
> > * Submit-Bugs-To
> > An mailto URL to which bugs should be submitted. (It's a URL so
> > we can support other types of BTSes at a later date if needed)
> > * Subm
On Sun, Jul 16, 2000 at 01:32:26PM -0400, Wichert Akkerman wrote:
> * Submit-Bugs-To
> An mailto URL to which bugs should be submitted. (It's a URL so
> we can support other types of BTSes at a later date if needed)
> * Submit-Bugs-Style
> Style in which submitted bugreports should be formatt
On Sun, 16 Jul 2000, Wichert Akkerman wrote:
> Package: packaging-manual
>
> I'm adding three new fields to debian/control:
>...
Sorry if I do perhaps address the wrong people, but I would like to
propose two other fields (there might be better names than the ones I
found):
Successor-Of:
As fa
Branden Robinson <[EMAIL PROTECTED]> wrote:
> Our Xaw-replacement handling is seriously pathological in every sense of
> the term.
>
> This will no longer be a concern in woody. With XFree86 4.0.1, libXaw is
> coming out of xlib6g and can be handled with the normal
> Conflicts/Replaces/Provides m
Hi,
> Date:Mon, 17 Jul 2000 01:29:18 MDT
> To: Wichert Akkerman <[EMAIL PROTECTED]>
> cc: debian-policy@lists.debian.org
> From:Jason Gunthorpe <[EMAIL PROTECTED]>
> Subject: Re: new fields in debian/control
>
> On Sun, 16 Jul 2000, Wichert Akkerman wrote:
>
> > * Origin
> >
On Sat, Jul 08, 2000 at 03:03:10AM -0700, Joey Hess wrote:
> see shy jo, who thinks we overuse the term "orthagonal" in Debian
Indeed. I'd prefer we used a term that was actually a word, and not some
weirdass misspelling of "orthogonal". :)
--
G. Branden Robinson | We either le
On Fri, Jul 07, 2000 at 05:18:59PM -0700, tony mancill wrote:
> There are two ways around this, but both would require a bit of policy.
> First, we could force the init.d scripts to use the -u command line option
> to the shell. (If an unset variable is referenced, the script will die. -
> sorta
On Thu, Jun 22, 2000 at 03:35:08PM +0200, Josip Rodin wrote:
> I agree with the spirit of this proposal, but the wording should be more
> explicit about what happens if the package wishes to add its directory into
> ld.so.conf. The Xaw library replacements do that, but it's not regulated by
> the P
Hi...
First, sorry for the crosspost. Do we want to go to a particular list for
this?
> Date:Mon, 17 Jul 2000 01:57:43 CDT
> To: Wichert Akkerman <[EMAIL PROTECTED]>
> cc: debian-devel@lists.debian.org, debian-dpkg@lists.debian.org,
>debian-policy@lists.debian.org, [EMAIL PR
Hi!
On Mon, 17 Jul 2000, Hamish Moffatt wrote:
> Wouldn't it be nicer to just put the Origin file in each package,
> and to have a database which maps origin -> submit-bugs-to and
> submit-bugs-style?
The style Wichert chose has the advantage that everybody can
create correct .debs. I doubt that
On Sun, Jul 16, 2000 at 01:32:26PM -0400, Wichert Akkerman wrote:
> * Origin
> This lists the origin of a package. For all Debian packages this should
> be `Debian'.
> * Submit-Bugs-To
> An mailto URL to which bugs should be submitted. (It's a URL so
> we can support other types of BTSes a
On Thu, Jul 13, 2000 at 07:17:02AM -0700, Joey Hess wrote:
> Josip Rodin wrote:
> > Oh, good! That means we need special arrangements only for other libs, those
> > that didn't use dh_shlibdeps in potato. I wonder what's the easiest way to
> > find them... grepping Lintian lab?
[...]
> This could c
Previously Wichert Akkerman wrote:
> I'm adding three new fields to debian/control:
[.. snip snip ..]
Okay, small update: I've renamed the bug fields:
Submit-Bugs-To-> Bugs-Submit-To
Submit-Bugs-Style -> Bugs-Submit-Style
Wichert.
--
_
Previously Joey Hess wrote:
> FWIW, debhelper already, and has always as far as I remember, ran
> dpkg-shlibdeps on all shared libraries[1] (because I couldn't find any docs
> that said not too, and it seemed like a good idea anyway). So that's 70%
> of the library packages, roughly, that need no a
Previously Manoj Srivastava wrote:
> However, there is nothing in here that is policy: to do
> otherwise would not work, and the paclage would break. I think we
> need to remove the aspects of the packaging manual that are merely
> documentation for dpkg out of the policy; just standard API's t
On Sun, 16 Jul 2000, Wichert Akkerman wrote:
> * Origin
> This lists the origin of a package. For all Debian packages this should
> be `Debian'.
This matches what is defined for the Release file..
> * Submit-Bugs-To
> An mailto URL to which bugs should be submitted. (It's a URL so
> we
On Sun, 16 Jul 2000, Wichert Akkerman wrote:
> Package: packaging-manual
>
> I'm adding three new fields to debian/control:
>
> * Origin
> This lists the origin of a package. For all Debian packages this should
> be `Debian'.
Is this created in debian/control by the maintainer, or should
Package: packaging-manual
I'm adding three new fields to debian/control:
* Origin
This lists the origin of a package. For all Debian packages this should
be `Debian'.
* Submit-Bugs-To
An mailto URL to which bugs should be submitted. (It's a URL so
we can support other types of BTSes at
46 matches
Mail list logo
