It seems like the common case for wanting to install a kernel module
source package is to build the module and then install it on the same
box. Since the *-source package doesn't really depend on *-utils, why
not add a Recommends line?
For example, ndiswrapper-source would Recommend ndiswrapper-u
On Mon, Jan 10, 2005 at 05:17:19PM -0600, Matthew Dempsky wrote:
> It seems like the common case for wanting to install a kernel module
> source package is to build the module and then install it on the same
> box. Since the *-source package doesn't really depend on *-utils, why
> not add a Recomm
Once upon a time Steve Langasek said...
>
> There is nothing in the -source package that actually requires (or should
> recommend) the -utils package. A much better fix here is for people to get
> over the fact that dpkg isn't apt.
Apologies for continuing this but having read through the thread
On Tue, Jan 11, 2005 at 11:15:26AM +1100, Cameron Hutchison wrote:
> Is this the scenario being argued over?
Yes, that was exactly what I had in mind
>If so, why does dpkg not first
> check the dependencies of foo-modules_2.0 before removing
> foo-modules_1.0?
"Because it's a low-level tool inte
On Tue, Jan 11, 2005 at 11:15:26AM +1100, Cameron Hutchison wrote:
> Once upon a time Steve Langasek said...
> >
> > There is nothing in the -source package that actually requires (or should
> > recommend) the -utils package. A much better fix here is for people to get
> > over the fact that dpkg
On Mon, Jan 10, 2005 at 05:36:50PM -0800, Steve Langasek wrote:
> dpkg doesn't do this because this isn't how dpkg works -- people wrote a
> higher-level tool, apt, to do that. People ignoring error messages from
> their package manager, breaking their system's network interface, and
> blaming the
Steve Langasek <[EMAIL PROTECTED]> writes:
> On Mon, Jan 10, 2005 at 05:17:19PM -0600, Matthew Dempsky wrote:
>> It seems like the common case for wanting to install a kernel module
>> source package is to build the module and then install it on the same
>> box. Since the *-source package doesn't
On Tue, 2005-01-11 at 11:15 +1100, Cameron Hutchison wrote:
> dpkg first removes foo-modules_1.0
> dpkg then check dependencies of foo-modules_2.0
> dpkg complains that foo-utils is not installed and aborts the
> installation of foo-modules_2.0
>
This is incorrect.
dpkg doesn't remove foo-module
On Tue, Jan 11, 2005 at 06:16:01AM +, Scott James Remnant wrote:
> dpkg doesn't remove foo-modules_1.0 at all.
I used equivs to make a package "foo", version 1.0, and installed it.
I used equivs to make a package "foo", version 2.0, which depend on
"bar", which doesn't exist. Tried to instal
On Tue, 2005-01-11 at 01:35 -0500, William Ballard wrote:
> On Tue, Jan 11, 2005 at 06:16:01AM +, Scott James Remnant wrote:
> > dpkg doesn't remove foo-modules_1.0 at all.
>
Note that I said "remove", the old files are replaced during the unpack
phase rather than removed.
It's generally ass
On Tue, Jan 11, 2005 at 06:53:57AM +, Scott James Remnant wrote:
> On Tue, 2005-01-11 at 01:35 -0500, William Ballard wrote:
>
> > On Tue, Jan 11, 2005 at 06:16:01AM +, Scott James Remnant wrote:
> > > dpkg doesn't remove foo-modules_1.0 at all.
> >
> Note that I said "remove", the old fi
On Mon, Jan 10, 2005 at 09:51:54PM -0600, Matthew Dempsky wrote:
> Steve Langasek <[EMAIL PROTECTED]> writes:
> > On Mon, Jan 10, 2005 at 05:17:19PM -0600, Matthew Dempsky wrote:
> >> It seems like the common case for wanting to install a kernel module
> >> source package is to build the module an
On Mon, Jan 10, 2005 at 11:07:52PM -0800, Steve Langasek wrote:
> in ways that were not backwards-compatible: automatically pulling in the
> -utils could render the system networkless before you've even started to
> *build* the modules...
In theory, yes if ndiswrapper-modules has a versioned depen
Once upon a time Scott James Remnant said...
> On Tue, 2005-01-11 at 11:15 +1100, Cameron Hutchison wrote:
>
> > dpkg first removes foo-modules_1.0
> > dpkg then check dependencies of foo-modules_2.0
> > dpkg complains that foo-utils is not installed and aborts the
> > installation of foo-modules_
On Tue, 2005-01-11 at 01:58 -0500, William Ballard wrote:
> On Tue, Jan 11, 2005 at 06:53:57AM +, Scott James Remnant wrote:
> > On Tue, 2005-01-11 at 01:35 -0500, William Ballard wrote:
> >
> > > On Tue, Jan 11, 2005 at 06:16:01AM +, Scott James Remnant wrote:
> > > > dpkg doesn't remove
On Tue, 2005-01-11 at 18:51 +1100, Cameron Hutchison wrote:
> Once upon a time Scott James Remnant said...
> > On Tue, 2005-01-11 at 11:15 +1100, Cameron Hutchison wrote:
> >
> > > dpkg first removes foo-modules_1.0
> > > dpkg then check dependencies of foo-modules_2.0
> > > dpkg complains that f
On Tue, Jan 11, 2005 at 08:16:47AM +, Scott James Remnant wrote:
> The files are not removed.
They ain't there no more. You can't use them.
You can't use the new files either until you do the things you specify.
If, for some reason, you cannot do the things you specify
(because the things wh
#include
* Scott James Remnant [Tue, Jan 11 2005, 08:19:21AM]:
> > dpkg unpacks the data contents (data.tar.gz) of foo-modules_2.0 into
> > their final location in the filesystem (possibly overwriting the
> > contents of the package being replaced)
> >
> > dpkg then checks dependencies of fo
On Tue, 2005-01-11 at 19:30 +0100, Eduard Bloch wrote:
> * Scott James Remnant [Tue, Jan 11 2005, 08:19:21AM]:
>
> > > dpkg complains that foo-utils is not installed and aborts the
> > > installation of foo-modules_2.0
> > >
> > dpkg does not abort the installation, the installation concludes
On Tue, Jan 11, 2005 at 07:10:42PM +, Scott James Remnant wrote:
> If you didn't want the package to be unpacked before its dependencies
> are installed, you'd just check the dependencies before unpacking.
Or use apt.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscr
Once upon a time Scott James Remnant said...
>
> Actually, this vastly depends on the package, but yes, in general an
> unpacked-but-not-configured package is not yet usable. And nor should
> it be.
Then wouldn't it make sense to avoid this state is possible? An unusable
package is obviously of
El mar, 11-01-2005 a las 02:21 -0500, William Ballard escribiÃ:
> On Mon, Jan 10, 2005 at 11:07:52PM -0800, Steve Langasek wrote:
> > in ways that were not backwards-compatible: automatically pulling in the
> > -utils could render the system networkless before you've even started to
> > *build* the
On Wed, Jan 12, 2005 at 12:27:11AM +0100, Jose Carlos Garcia Sogo wrote:
> No, but it is for a -source package.
? Think about what you're saying. It's "anathema" to install it? Or
"anathema" to force you to install it? I checked and several of the the
*-source packages Suggest the utils; som
On Tue, Jan 11, 2005 at 09:43:21AM -0500, William Ballard wrote:
> They ain't there no more. You can't use them.
William, you aren't using 'remove' in the same sense Scott and Cameron
were. Remember this started when Cameron posited a sequence of
operations that dpkg might be going through. Sc
What would be the impact on (c)debootstrap of changing the operation
of dpkg? I haven't looked at the exact sequence in a while, but IIRC
those partially-installed states have valid uses in a debootstrap run.
For instance, an unconfigured package may not be ready for normal
use, but may get some
On Wed, Jan 12, 2005 at 04:23:19PM +1100, Vincent Ho wrote:
> entitled to be precise when saying that the files are not removed (as
> canvassed by Cameron), but overwritten. Please accept gracefully that
And *I'm* being precise when I said "foo 1.0" is removed and not
replaced. A package is not
On Tue, Jan 11, 2005 at 09:57:23PM -0800, Michael K. Edwards wrote:
> I think I'm of the "it's a low-level tool, you can shoot yourself in
> the foot if you insist on it" school.
Then the problem is source packages force you to use this low level too.
That's why I said I will never install a pack
On Wed, 12 Jan 2005 01:15:01 -0500, William Ballard
<[EMAIL PROTECTED]> wrote:
> On Tue, Jan 11, 2005 at 09:57:23PM -0800, Michael K. Edwards wrote:
> > I think I'm of the "it's a low-level tool, you can shoot yourself in
> > the foot if you insist on it" school.
>
> Then the problem is source pac
On Wed, Jan 12, 2005 at 01:12:08AM -0500, William Ballard wrote:
> And *I'm* being precise when I said "foo 1.0" is removed and not
> replaced.
This is what Cameron said:
> > User runs "dpkg -i foo-modules_2.0_arch.deb"
> >
> > dpkg first removes foo-modules_1.0
> > dpkg then check dependencie
* Scott James Remnant <[EMAIL PROTECTED]> [050111 20:10]:
> > Of course this is the right way to do, but sometimes users are
> > lazy (or just expect different things, and some of them appear here,
> > with their arrogant attitude, pissed and beeing polemic).
> >
> Actually users will be more like
On Tue, 2005-01-11 at 21:57 -0800, Michael K. Edwards wrote:
> What would be the impact on (c)debootstrap of changing the operation
> of dpkg?
>
Forget the impact on debootstrap, the impact on APT and dselect is
pretty huge. dpkg is designed to be able to unpack packages while their
dependencies
On Wed, Jan 12, 2005 at 03:06:06PM +, Scott James Remnant wrote:
> What William Ballard, Cameron Hutchinson and Eduard Bloch are asking for
> is to remove the difference between Depends and Pre-Depends and make all
> Depends behave like Pre-Depends.
No: I do not want dependencies to be INSTALL
Steve Langasek <[EMAIL PROTECTED]> writes:
> Recommends means "packages that would be found together with this one in all
> but unusual installations". It is not unusual to have a single designated
> build machine in an organization, which may or may not ever have the final
> binary packages inst
On Wed, Jan 12, 2005 at 10:05:00AM -0600, Matthew Dempsky wrote:
> Steve Langasek <[EMAIL PROTECTED]> writes:
>
> > Recommends means "packages that would be found together with this one in all
> > but unusual installations". It is not unusual to have a single designated
> > build machine in an or
On Wed, 12 Jan 2005 10:05:00 -0600, Matthew Dempsky wrote:
[...]
> If a new version of ndiswrapper-utils is not backwards-compatible with
> an old version of ndiswrapper-modules, shouldn't it declare a
> versioned Conflicts with those older versions or else when you try to
> upgrade you'll have pro
Scripsit Scott James Remnant <[EMAIL PROTECTED]>
> Forget the impact on debootstrap, the impact on APT and dselect is
> pretty huge. dpkg is designed to be able to unpack packages while their
> dependencies are not yet fulfilled.
But don't apt and dselect already invoke dpkg with special options
On Wed, 2005-01-12 at 18:28 +, Henning Makholm wrote:
> Scripsit Scott James Remnant <[EMAIL PROTECTED]>
>
> > What's interesting is nobody has jumped in on this thread to point out
> > that dpkg *has* a dependency field for forcing checking of dependencies
> > before the package is unpacked.
On Wednesday 12 January 2005 11:52 am, Scott James Remnant wrote:
> It's breaking elegance to fix something I'm not convinced is a problem.
Just to be clear: you mean the elegance of the dpkg code, not its external
behavior, right? Because I don't see anything elegant about erroring out and
l
On Wed, 2005-01-12 at 12:26 -0800, Daniel Burrows wrote:
> On Wednesday 12 January 2005 11:52 am, Scott James Remnant wrote:
> > It's breaking elegance to fix something I'm not convinced is a problem.
>
> Just to be clear: you mean the elegance of the dpkg code, not its external
> behavior, ri
On Wed, Jan 12, 2005 at 08:37:04PM +, Scott James Remnant wrote:
> Why not? It means that you just need to go fetch and install the
> dependency, you don't need to try and install the depending package
> again.
Yeah, that's real "elegant."
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with
On Wednesday 12 January 2005 12:37 pm, Scott James Remnant wrote:
> On Wed, 2005-01-12 at 12:26 -0800, Daniel Burrows wrote:
> > On Wednesday 12 January 2005 11:52 am, Scott James Remnant wrote:
> > > It's breaking elegance to fix something I'm not convinced is a problem.
> >
> > Just to be clear
Scripsit Scott James Remnant <[EMAIL PROTECTED]>
> On Wed, 2005-01-12 at 12:26 -0800, Daniel Burrows wrote:
>> Just to be clear: you mean the elegance of the dpkg code, not its
>> external behavior, right? Because I don't see anything elegant
>> about erroring out and leaving an operation half-c
On Wed, Jan 12, 2005 at 01:38:28PM -0500, Andres Salomon wrote:
> Of course. No one has provided proof that this is the case, though. I
> asked if a versioned depends was necessary, but instead got accusations
> and vitriol. I have not had time to test it myself yet.
Some of the other *-source
* Daniel Burrows <[EMAIL PROTECTED]> [050112 22:08]:
> Well, you're also leaving the package in a broken and unconfigured state.
> Doing this in order to save the user a little typing later (adding the
> original package to the second --install line) seems to me like a hack to
> make some use
On Thu, Jan 13, 2005 at 12:26:31PM +0100, Bernhard R. Link wrote:
> It would also break serialisation, as one would need to give a list of
> packages to install to dpkg all at once or in the correct serialisation,
> and no longer (with exception of configure cycles) beeing able to give
> them in wh
I demand that Scott James Remnant may or may not have written...
[snip]
> And a far better solution to the "a package on disk needs dependencies"
> solution is for a command-line tool that can grab the dependencies a
> package needs, not just bitch about them not existing.
apt* with an install-fr
Scripsit "Bernhard R. Link" <[EMAIL PROTECTED]>
> The elegance is that dpkg is robust in that it can always install
> everything and can get cleanly from one state to another. However broken
> the packages are you never end in a sitation you cannot fix again.
How would this property be lost if dp
On Thu, 2005-01-13 at 17:06 +, Darren Salt wrote:
> I demand that Scott James Remnant may or may not have written...
>
> [snip]
> > And a far better solution to the "a package on disk needs dependencies"
> > solution is for a command-line tool that can grab the dependencies a
> > package need
Cameron Hutchison <[EMAIL PROTECTED]> writes:
> Once upon a time Steve Langasek said...
>>
>> There is nothing in the -source package that actually requires (or should
>> recommend) the -utils package. A much better fix here is for people to get
>> over the fact that dpkg isn't apt.
>
> Apologie
Scott James Remnant <[EMAIL PROTECTED]> writes:
> On Tue, 2005-01-11 at 01:35 -0500, William Ballard wrote:
>
>> On Tue, Jan 11, 2005 at 06:16:01AM +, Scott James Remnant wrote:
>> > dpkg doesn't remove foo-modules_1.0 at all.
>>
> Note that I said "remove", the old files are replaced during
"Michael K. Edwards" <[EMAIL PROTECTED]> writes:
> What would be the impact on (c)debootstrap of changing the operation
> of dpkg? I haven't looked at the exact sequence in a while, but IIRC
> those partially-installed states have valid uses in a debootstrap run.
> For instance, an unconfigured
Scott James Remnant <[EMAIL PROTECTED]> writes:
> On Tue, 2005-01-11 at 21:57 -0800, Michael K. Edwards wrote:
>
>> What would be the impact on (c)debootstrap of changing the operation
>> of dpkg?
>>
> Forget the impact on debootstrap, the impact on APT and dselect is
> pretty huge. dpkg is desi
Scott James Remnant <[EMAIL PROTECTED]> writes:
> On Wed, 2005-01-12 at 18:28 +, Henning Makholm wrote:
>
>> Scripsit Scott James Remnant <[EMAIL PROTECTED]>
>>
>> > What's interesting is nobody has jumped in on this thread to point out
>> > that dpkg *has* a dependency field for forcing chec
"Bernhard R. Link" <[EMAIL PROTECTED]> writes:
> * Daniel Burrows <[EMAIL PROTECTED]> [050112 22:08]:
>> Well, you're also leaving the package in a broken and unconfigured state.
>> Doing this in order to save the user a little typing later (adding the
>> original package to the second --inst
Scott James Remnant <[EMAIL PROTECTED]> writes:
> On Tue, 2005-01-11 at 19:30 +0100, Eduard Bloch wrote:
>
>> * Scott James Remnant [Tue, Jan 11 2005, 08:19:21AM]:
>>
>> > > dpkg complains that foo-utils is not installed and aborts the
>> > > installation of foo-modules_2.0
>> > >
>> > dpkg do
On Sat, Jan 15, 2005 at 08:40:56AM +0100, Goswin von Brederlow wrote:
> Afaik neither debootstrap, cdebootstrap nor rootstrap use dpkg -i to
> partially install packages. They explicitly use --unpack and
> --configure and use --force-* options to exactly say what they need.
rootstrap doesn't inst
Matt Zimmerman <[EMAIL PROTECTED]> writes:
> On Sat, Jan 15, 2005 at 08:40:56AM +0100, Goswin von Brederlow wrote:
>
>> Afaik neither debootstrap, cdebootstrap nor rootstrap use dpkg -i to
>> partially install packages. They explicitly use --unpack and
>> --configure and use --force-* options to e
57 matches
Mail list logo
