Bug#75505: base: mod(utils?)conf should not overwrite /etc/modules.conf

[KoV]

Package: base
Version: 20001024
Severity: normal

I think modules.conf should not be overwritten on an upgrade of it's utils
I always lost every configuration I have done for my soundcard and my isdn
modules whenever I upgrade to new versions of modutils (modconf?) shouldn't
it be put at conffiles ;)?

-- System Information
Debian Release: woody
Kernel Version: Linux couve 2.2.17 #6 sáb out 7 21:12:11 BRST 2000 i586 unknown



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#75505: base: mod(utils?)conf should not overwrite /etc/m

[Sean 'Shaleh' Perry]

On 24-Oct-2000 KoV wrote:
> Package: base
> Version: 20001024
> Severity: normal
> 
> I think modules.conf should not be overwritten on an upgrade of it's utils
> I always lost every configuration I have done for my soundcard and my isdn
> modules whenever I upgrade to new versions of modutils (modconf?) shouldn't
> it be put at conffiles ;)?
> 

/etc/modutils/foo.  You put your changes there and update-modules reads it and
autogenerates the modules.conf and what not.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#75505: marked as done (base: mod(utils?)conf should not overwrite /etc/modules.conf)

[Debian Bug Tracking System]

Your message dated Wed, 25 Oct 2000 00:07:53 +0200
with message-id <[EMAIL PROTECTED]>
and subject line Bug#75505: base: mod(utils?)conf should not overwrite /etc/m
has caused the attached Bug report to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere.  Please contact me immediately.)

Darren Benham
(administrator, Debian Bugs database)

--
Received: (at submit) by bugs.debian.org; 24 Oct 2000 20:35:39 +
>From [EMAIL PROTECTED] Tue Oct 24 15:35:39 2000
Return-path: <[EMAIL PROTECTED]>
Received: from esparta.brfree.com.br (brfree.com.br) [:::200.192.60.6] 
by master.debian.org with smtp (Exim 3.12 1 (Debian))
id 13oAnK-0001rX-00; Tue, 24 Oct 2000 15:35:39 -0500
Received: (qmail 17046 invoked from network); 24 Oct 2000 20:41:31 -
Received: from bh-234-154.brfree.com.br (HELO couve) (200.190.234.154)
  by esparta.brfree.com.br with SMTP; 24 Oct 2000 20:41:31 -
Received: by zaz.com.br
via sendmail from stdin
id <m13oAkj-002EYsC@couve> (Debian Smail3.2.0.111)
for [EMAIL PROTECTED]; Tue, 24 Oct 2000 18:32:57 -0200 (BRST) 
Message-Id: <m13oAkj-002EYsC@couve>
Date: Tue, 24 Oct 2000 18:32:57 -0200 (BRST)
From: Gustavo Noronha Silva (KoV) <[EMAIL PROTECTED]>
Subject: base: mod(utils?)conf should not overwrite /etc/modules.conf
To: [EMAIL PROTECTED]
Bcc:
X-Mailer: bug 3.3.6
Delivered-To: [EMAIL PROTECTED]

Package: base
Version: 20001024
Severity: normal

I think modules.conf should not be overwritten on an upgrade of it's utils
I always lost every configuration I have done for my soundcard and my isdn
modules whenever I upgrade to new versions of modutils (modconf?) shouldn't
it be put at conffiles ;)?

-- System Information
Debian Release: woody
Kernel Version: Linux couve 2.2.17 #6 sáb out 7 21:12:11 BRST 2000 i586 unknown


---
Received: (at 75505-done) by bugs.debian.org; 24 Oct 2000 22:08:01 +
>From [EMAIL PROTECTED] Tue Oct 24 17:08:01 2000
Return-path: <[EMAIL PROTECTED]>
Received: from voyager.cistron.net (smtp.cistron.nl) [:::195.64.68.34] 
by master.debian.org with esmtp (Exim 3.12 1 (Debian))
id 13oCEh-0001qZ-00; Tue, 24 Oct 2000 17:07:59 -0500
Received: from picard.cistron.nl ([195.64.65.20])
by smtp.cistron.nl with esmtp (Exim 3.13 #1 (Debian))
id 13oCEr-0004Lu-00; Wed, 25 Oct 2000 00:08:09 +0200
Received: (from wichert@localhost)
by picard.cistron.nl (8.9.3/8.9.3/Debian 8.9.3-6) id AAA30539;
Wed, 25 Oct 2000 00:07:53 +0200
Date: Wed, 25 Oct 2000 00:07:53 +0200
From: Wichert Akkerman <[EMAIL PROTECTED]>
To: "Sean 'Shaleh' Perry" <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
Subject: Re: Bug#75505: base: mod(utils?)conf should not overwrite /etc/m
Message-ID: <[EMAIL PROTECTED]>
References: <m13oAkj-002EYsC@couve> <[EMAIL PROTECTED]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <[EMAIL PROTECTED]>; from [EMAIL PROTECTED] on 
Tue, Oct 24, 2000 at 01:56:14PM -0700
Delivered-To: [EMAIL PROTECTED]

Previously Sean 'Shaleh' Perry wrote:
> /etc/modutils/foo.  You put your changes there and update-modules reads it and
> autogenerates the modules.conf and what not.

Indeed. If you look at /etc/modules.conf the first lines state very
explicitly that you should never modify it since it is a generated
file.

I'm closing this bugreport.

Wichert.

-- 
   
 / Generally uninteresting signature - ignore at your convenience  \
| [EMAIL PROTECTED]  http://www.liacs.nl/~wichert/ |
| 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0  2805 3CB8 9250 2FA3 BC2D |


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: busybox in main

[Joey Hess]

I would respond to this point by point but it probably suffices to say
that we have discussed with James how the debian-installer packages can
fit into the archive, and once the new package pool stuff moves into
place James is pretty sure it will be easy to do and has committed to
doing it.

The binary packages (installer modules) will not be going into
the main/binary-foo directories, and will not be in the Packages files or
anything, so we are going to feel free to ignore policy in them, much as
we would feel free to ignore policy if we had decided to use the RPM
package format as the *internal module format* of the debian installer.

And sometimes I think that would have been easier. Sheesh.

Antti-Juhani Kaijanaho wrote:
> On 20001018T104910-0600, Erik Andersen wrote:
> > Before packaging it up, I asked on debian-boot if policy
> > compliance was required for this package, or if it should only contain the
> > binaries.  In that discussion, we made the decision that installer specific
> > packages do not need to be policy compliant.  This decision was made by Joey
> > Hess, project leader for the woody debian-installer.
> 
> Oh, I was not aware that Joey is the current policy czar.
> 
> (For the record, we don't have policy czars anymore.)
> 
> > Until I am informed by
> > the woody debian-installer project leader that something else has been decided,
> > I will continue to assuming that we are merely waiting for the archive to be
> > updated to support debian-installer specific packaged with a new "installer"
> > section.
> 
> You are actually waiting for a decision to be made.  The debian-installer
> project leader does not have the authority to decide these things -
> what you are suggesting requires a consensus among Debian developers at
> minimum (ie. a flamewar on -devel) and possibly a Debian Policy change
> (which requires certain hoops to be jumped through on the -policy list).
> It definitely *cannot* be decided by the install system team alone.
> (Which is, BTW, a point I already made those months ago in my reject
> message.)
> 
> -- 
> %%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%%
> 
> 
> -- 
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
> 

-- 
see shy jo


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: busybox in main

[Roland Bauerschmidt]

On Mon, Oct 23, 2000 at 10:35:37PM -0700, Joey Hess wrote:
> The binary packages (installer modules) will not be going into
> the main/binary-foo directories, and will not be in the Packages files or
> anything, so we are going to feel free to ignore policy in them, much as
> we would feel free to ignore policy if we had decided to use the RPM
> package format as the *internal module format* of the debian installer.
> 
> And sometimes I think that would have been easier. Sheesh.

Is this a challenge for a flame war? Just kidding...

Roland

-- 
Roland Bauerschmidt <[EMAIL PROTECTED]>


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: busybox in main

[Anthony Towns]

On Mon, Oct 23, 2000 at 10:35:37PM -0700, Joey Hess wrote:
> I would respond to this point by point but it probably suffices to say
> that we have discussed with James how the debian-installer packages can
> fit into the archive, and once the new package pool stuff moves into
> place James is pretty sure it will be easy to do and has committed to
> doing it.

Note that this isn't putting them into `main' in the usual sense (which
was the sense people were talking about a while ago), but rather just
changing the disks-* directories to be a little more like the binary-*
directories.

It might, at some point, become useful for there to be some mini-policy
about these debs, or even for it to just be put in policy proper.

The following's the only productive piece of this email, and followups
should probably be just to -boot.

How should these udebs be treated by testing?

My understanding is that the new d-i archive will work essentially
as follows:

dists/ stable/ main/
binary-i386/
various .debs
disks-i386/
various .udebs
some basic boot-floppies
release notes
source/
source to all the .debs and .udebs

Am I also correct in thinking that each udeb will be generated from a
single auto-buildable .dsc? That'd be really impressive if you could pull
it off. Am I at least correct in assuming each has an associated .dsc?
I suspect package-pools will necessitate this.

The way testing works is to pick and choose new source files and run
various checks on the associated debs (like "do they match the source, or
are they out of date" and "will they be installable").

The easiest way for me to handle udebs (I think) is to just to completely
ignore them: so if all of a package's .debs are okay (and if there are none
of them this is trivially true), then it's okay to go in testing. If any of
them aren't, they're not.

But this will probably cause breakages in testing's boot floppies, which
I consider a very bad thing. So I guess another possibility would be to
just treat the disks-* stuff as another architecture just like binary-*
at the moment. Does that make sense? Will disks-* have Packages files?
Will the dependencies make sense?

Hmmm. Am I missing something? Treating disks-* as just another
architecture sounds much more appealing now than it did before. Are there
any cross-dependencies that I'd have to worry about (ie, a .deb depending
on a .udeb or vice-versa, without there being a real .deb (resp. .udeb)
that'd also satisfy the dependency)? I assume not.

Would it be possible, do people think, to have (eg) a release-notes.udeb
from which a script on ftp-master automatically extracts the release notes
and dumps them somewhere useful? Ditto vmlinuz, and the boot-floppies
themselves?

Cheers,
aj

-- 
Anthony Towns <[EMAIL PROTECTED]> 
I don't speak for anyone save myself. GPG signed mail preferred.

  ``We reject: kings, presidents, and voting.
 We believe in: rough consensus and working code.''
  -- Dave Clark

 PGP signature

Re: busybox in main

[Glenn McGrath]

Roland Bauerschmidt wrote:
> 
> On Mon, Oct 23, 2000 at 10:35:37PM -0700, Joey Hess wrote:
> > The binary packages (installer modules) will not be going into
> > the main/binary-foo directories, and will not be in the Packages files or
> > anything, so we are going to feel free to ignore policy in them, much as
> > we would feel free to ignore policy if we had decided to use the RPM
> > package format as the *internal module format* of the debian installer.
> >
> > And sometimes I think that would have been easier. Sheesh.
> 
> Is this a challenge for a flame war? Just kidding...
> 
> Roland
> 

Whats the point in following a policy that just gets in the road.

I really dont understand why our (the installer team) work has to get
pushed away into some dark hidden corner.

My personal opinion is that Joey is trying to make a compromise by
having a seperate area for installer packages, but as far as i know the
installer team has no idea whatsoever if or when there will be a
seperate area to put installer specific modules.

There is an internal deadline of a few months to be able to demonstrate
how the new installer might work, if we dont meet this deadline, presure
will be one to go back and revamp the old installer for woody. Is it too
much to expect that in a few months when binary packages are available
there will be somewhere official to put binary packages.

As far as busybox goes, it started of as a debian project for the
installer team (?) years ago and has grown to be quite popular in
embedded systems, it is a usefull package to have laying around, and i
dont see why people shouldnt be able to install it in binary form.

If policy prevents users from easily installing usefull emergency
utilities then it is clear to me at least then something is wrong with
policy.


Glenn


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: busybox in main

[Erik Andersen]

On Mon Oct 23, 2000 at 10:35:37PM -0700, Joey Hess wrote:
> 
> And sometimes I think that would have been easier. Sheesh.

Indeed.  I'm glad to see some progress finally happening though... 

 -Erik

--
Erik B. Andersen   email:  [EMAIL PROTECTED]
--This message was written using 73% post-consumer electrons--


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: busybox in main

[Joey Hess]

Glenn McGrath wrote:
> My personal opinion is that Joey is trying to make a compromise by
> having a seperate area for installer packages, but as far as i know the
> installer team has no idea whatsoever if or when there will be a
> seperate area to put installer specific modules.

Allright, let me clear some of this up. We had a conversation with James
Troup last week in irc about this, and I was going to write it up, but
my move interveined. Here's what I remember:

* We agreed that it makes sense to have a special directory for the
  debian-installer binaries. There is a close parallell to the
  disks- directories that are used for the boot floppies, and we
  might use a subdirectory of them, or some other directory name, it
  doesn;t really matter.
* Our little directory will have its own Packages file. I want this,
  because retreivers should be able to use a Packages file that have
  only relevant debian-install-specific package (modules) in it.
* Uploading files and getting them into such a special-purpose little
  directory rather than having them auto-processed requires marking them
  as "byhand" in the .changes file.
* We don't really want to overload the ftp maintainers with a lot of
  byhand uploads, so it would be nice to automate that.
* James is confident that as soon as the archive begins using the
  package pool stuff he wrote, he can easily make his replacement for
  dinstall handle our byhand packes aytomatically or something, and
  update our Packages file too. (The current dinstall could do it too,
  I'm sure, but at least James understands the code to the new one..)
* Because of some objections by Adam Heath that he doesn't want to see
  .debs uploaded to the archive, even if it's to a hidden away corner
  that's not aptable, we decided to use the extention ".udeb" for debian
  installer modules. It will probably make James's code easier anyway,
  and it's not much harder to build fdebs with a different extention,
  and most tools will work fine no matter that the filename is.
* None of this has mentioned where sources go. Sources go into the MAIN
  archive. Some sources (like busybox, ash, etc), will generate .deb's and
  .udeb's. Others won't generate any .debs, but this is ok.

-- 
see shy jo


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: busybox in main

[Glenn McGrath]

Joey Hess wrote:
> 
> Glenn McGrath wrote:
> > My personal opinion is that Joey is trying to make a compromise by
> > having a seperate area for installer packages, but as far as i know the
> > installer team has no idea whatsoever if or when there will be a
> > seperate area to put installer specific modules.
> 
> Allright, let me clear some of this up. We had a conversation with James
> Troup last week in irc about this, and I was going to write it up, but
> my move interveined. Here's what I remember:
> 


> * Our little directory will have its own Packages file. I want this,
>   because retreivers should be able to use a Packages file that have
>   only relevant debian-install-specific package (modules) in it.

Oh yea, this will save heaps of space on ramdisk (or wherever)
considering a Packages is 3 or 4MB 


> * Because of some objections by Adam Heath that he doesn't want to see
>   .debs uploaded to the archive, even if it's to a hidden away corner
>   that's not aptable, we decided to use the extention ".udeb" for debian
>   installer modules. It will probably make James's code easier anyway,
>   and it's not much harder to build fdebs with a different extention,
>   and most tools will work fine no matter that the filename is.

What if debian install requires a stock standard package thats in main,
does that package have to be in both archives?

> * None of this has mentioned where sources go. Sources go into the MAIN
>   archive. Some sources (like busybox, ash, etc), will generate .deb's and
>   .udeb's. Others won't generate any .debs, but this is ok.
> 
Woohoo, thats a win.


Mabye in the long run some sort of sub-packaging system may be
apropriate, that way the installer could extract some binaries from
existing verified policy compliant packages. But thats probably looking
to far ahead.


Glenn


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: busybox in main

[Adam Di Carlo]

On Wed, Oct 25, 2000 at 01:59:06PM +1000, Anthony Towns wrote:
> My understanding is that the new d-i archive will work essentially
> as follows:
> 
>   dists/ stable/ main/
>   binary-i386/
>   various .debs
>   disks-i386/
>   various .udebs
>   some basic boot-floppies
>   release notes
>   source/
>   source to all the .debs and .udebs

I don't like this scheme because it's assuming either/or with debian-installer vs
boot-floppies.  Forcing this either/or decision is going to make releasing woody a lot
harder.

> Would it be possible, do people think, to have (eg) a release-notes.udeb
> from which a script on ftp-master automatically extracts the release notes
> and dumps them somewhere useful? Ditto vmlinuz, and the boot-floppies
> themselves?

Um, I don't know -- w.r.t. boot-floppies, probably not.  

-- 
.Adam Di [EMAIL PROTECTED]http://www.onShore.com/>


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]