Re: MAKEDEV in postinst files

2000-07-19 Thread Sean 'Shaleh' Perry
> > Good point, but it's still a question. In fact adding debconf support > raises the interesting question - what severity should the question be - > critical? > > The package I'm maintaining (tpctl) adds /dev/thinkpad (root.root > 0660) and so "low" would seem more appropriate - in fact not as

Re: MAKEDEV in postinst files

2000-07-19 Thread Adrian Bridgett
On Wed, Jul 19, 2000 at 11:40:10 -0700 (+), Sean 'Shaleh' Perry wrote: > > On 18-Jul-2000 Adrian Bridgett wrote: > > Debian policy says: > > 4.6. Device files > > - > > No package may include device files in the package file tree. > > > > If a package needs any special device

Re: new fields in debian/control

2000-07-19 Thread Jeff Teunissen
Ben Collins wrote: > > That makes sense, but doesn't sound like a good idea to me. People would > start removing debconf after every upgrade, only to redownload and install > it the next time that upgrade. This goes for several other packages > aswell. Probably, if this is ever implemented, then i

RE: MAKEDEV in postinst files

2000-07-19 Thread Sean 'Shaleh' Perry
On 18-Jul-2000 Adrian Bridgett wrote: > Debian policy says: > 4.6. Device files > - > No package may include device files in the package file tree. > > If a package needs any special device files that are not included in the > base system, it has to call `makedev' in the `postinst

Re: new fields in debian/control

2000-07-19 Thread Gopal Narayanan
On Wed, Jul 19, 2000 at 11:44:33AM -0400, Ben Collins wrote: > On Wed, Jul 19, 2000 at 11:00:31AM -0400, Gopal Narayanan wrote: > > While we are on the topic of items to add to debian/control, I would > > like to suggest > > > > * Install-Depends > > > > This field could be used to specify packag

Re: new fields in debian/control

2000-07-19 Thread Adam Heath
On Mon, 17 Jul 2000, Wichert Akkerman wrote: > 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 d

Re: new fields in debian/control

2000-07-19 Thread Hartmut Koptein
> > * 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 a later date if needed) > > * Submit-Bugs-Style > >

MAKEDEV in postinst files

2000-07-19 Thread Adrian Bridgett
Debian policy says: 4.6. Device files - No package may include device files in the package file tree. If a package needs any special device files that are not included in the base system, it has to call `makedev' in the `postinst' script, after asking the user for permission to do

Re: new fields in debian/control

2000-07-19 Thread Ben Collins
On Wed, Jul 19, 2000 at 11:00:31AM -0400, Gopal Narayanan wrote: > On Sun, Jul 16, 2000 at 01:32:26PM -0400, 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 pac

Re: new fields in debian/control

2000-07-19 Thread Gopal Narayanan
On Sun, Jul 16, 2000 at 01:32:26PM -0400, 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'. > * Submit-Bugs-To > An mailto URL to whi

Re: new fields in debian/control

2000-07-19 Thread Clint Adams
> If it turns out to be generally useful, should we not > at least consider building it in, rahter than asking everyone to hack > their own variant? I think that the Origin is corelated to the BTS, > and the BTS is trongly related to the style, and this should be > reflected in the implem

Bug#66023: PROPOSAL] Treat plugins and shared libraries differently

2000-07-19 Thread Branden Robinson
On Mon, Jul 17, 2000 at 12:31:10PM +0100, Edward Betts wrote: > 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

Re: new fields in debian/control

2000-07-19 Thread Branden Robinson
On Mon, Jul 17, 2000 at 05:59:02PM -0600, Jason Gunthorpe wrote: > On Tue, 18 Jul 2000, Wichert Akkerman wrote: > > Even if Corel or Stormix ship a Debian package, it is still *our* > > package and we are responsible for it. So we should also get the > > bugreports. [...] > Can you imagine how badl

Re: new fields in debian/control

2000-07-19 Thread Branden Robinson
On Mon, Jul 17, 2000 at 02:33:34PM +0200, Adrian Bunk wrote: > 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 old package). There must't be more

Re: new fields in debian/control

2000-07-19 Thread Branden Robinson
On Mon, Jul 17, 2000 at 01:37:17PM -0400, Clint Adams wrote: > 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, what purpose does it serve > to hav