Hi
first I'm just a debian-user, if you guys don't mind my 2 cents then
here it is:
I think a task packages is a bad approach to the too-many-packages
problems. The organisation of the packages shouldn't be part of the
dependency system, IMHO. This organization is intended to help clue-less
Joey Hess [EMAIL PROTECTED] writes:
Christoph Martin wrote:
So, what is the policy to do with a package for the testing
distribution, if there is an important bug? Do you remove the package
unconditionaly or do you try investigate (like in the rc buglist) if
the bug really applies?
On Thu, Aug 17, 2000 at 10:17:30PM +1000, Anthony Towns wrote:
Hello world,
So, on -devel-announce, I mentioned:
* New testing distribution
[...]
So some more details.
The way testing is supposed to work is to have three distributions at
any one time: a stable tree, a testing tree, and
On Fri, 18 Aug 2000, Edward Betts wrote:
I agreed with everything else that you said, you give a good example of how
subpackaging could be implemented using dpkg. However, one of my concerns as a
low bandwidth user is transferring stuff. Great, I can split my debs up into
subpackages inside
On Fri, 18 Aug 2000, Anthony Towns wrote:
Presumably sections and tasks will both be subsumed by this. I think
these should probably be handled differently: saying I want the games
task should probably default to installing all; whereas you'd probably
not want to say I want the games section
On Thu, Aug 17, 2000 at 08:58:31PM +0100, Edward Betts wrote:
How about a little brainstorming to pick some categories that could be used
in debian.
Possible layout
~~~
control.tar.gzpackage system stuff, depends, postinst, etc
signatures.tar.gz signatures
On Tue, Aug 15, 2000 at 12:28:12AM -0600, Jason Gunthorpe wrote:
Well, this is what I was trying to say before - logically it makes alot of
sense if packages are members of groups, this is the reverse of what we
have now - a list of packages in a group.
Delivery and storage of this data has
Joey Hess [EMAIL PROTECTED] writes:
It's beautiful. I want it now. :-)
I couldn't agree more.
We could always fine tune it when we know how it works with live
data. But I think you'right. Some way of chrash-install into testing
would be nice when dealing with root-exploits.
--
Peter
On Thu, Aug 17, 2000 at 10:17:30PM +1000, Anthony Towns wrote:
Automated Process?
~~
So pretty much all the policy is encoded in some automated process
which updates testing. It works at the moment, basically as follows:
1. First, it loads up all the Sources and
On Fri, Aug 18, 2000 at 10:34:35AM +0100, Jules Bean wrote:
I'd just like to bring up the only point which really worries me about
all this... what is the incentive for people to run their machines on
'unstable'?
Because a package lying for 3 weeks in unstable says nothing about it
being
On Fri, Aug 18, 2000 at 09:26:34PM +1000, Anthony Towns wrote:
Another reason to run unstable is to live on the actual bleeding edge:
testing will always be around two weeks out of date. That can be a fair
while, if you're impatient.
Supporting this, there's some Apt changes in CVS that'll
Anthony Towns aj@azure.humbug.org.au wrote:
First, including each architecture and source in every .deb suddenly
balloons our 3 CD set to get i386 binaries to a ~15 CD set. It also
kills non-broadband net upgrades (you *really* want to download six
copies of emacs plus all its source?). I'm
Jules Bean [EMAIL PROTECTED] wrote:
I'd just like to bring up the only point which really worries me about
all this... what is the incentive for people to run their machines on
'unstable'?
I for one like the bleeding-edge. I like stuff that breaks, because I get to
fix it. I like filing bug
Anthony Towns aj@azure.humbug.org.au wrote:
On Thu, Aug 17, 2000 at 08:58:31PM +0100, Edward Betts wrote:
First, including each architecture and source in every .deb suddenly
balloons our 3 CD set to get i386 binaries to a ~15 CD set. It also
kills non-broadband net upgrades (you *really* want
On 18-Aug-00, 06:26 (CDT), Anthony Towns aj@azure.humbug.org.au wrote:
Supporting this, there's some Apt changes in CVS that'll let people choose
a few packages from one distribution and leave the rest from another.
To whoever implemented this feature: ThankyouThankyouThankyou -- it's
On Fri, 18 Aug 2000, Edward Betts wrote:
Jules Bean [EMAIL PROTECTED] wrote:
I'd just like to bring up the only point which really worries me about
all this... what is the incentive for people to run their machines on
'unstable'?
I for one like the bleeding-edge. I like stuff that
On Fri, Aug 18, 2000 at 10:34:35AM +0100, Jules Bean wrote:
I'd just like to bring up the only point which really worries me about
all this... what is the incentive for people to run their machines on
'unstable'?
In my case curiosity to test new stuff without having to deal with
the other
Anthony Towns aj@azure.humbug.org.au writes:
Another reason to run unstable is to live on the actual bleeding edge:
testing will always be around two weeks out of date. That can be a fair
while, if you're impatient.
At best. Please remember there are some maintainers that will have to
I'd just like to bring up the only point which really worries me about
all this... what is the incentive for people to run their machines on
'unstable'?
I don't know - how many people are running glibc 2.1.92 now? How about X
4.0? GNAT 3.13? I'm running two out the three, because I'm too
Joey Hess writes:
Christoph Martin wrote:
We have a problem with the bug tracking system as long as we can't
really find out to which versions of a package a bug really
applies. We only mosttimes have the version of the packages where a
problem showed up. But we don't know if the bug
Christoph Martin wrote:
So, what is the policy to do with a package for the testing
distribution, if there is an important bug? Do you remove the package
unconditionaly or do you try investigate (like in the rc buglist) if
the bug really applies?
Well if I were AJ I would just mechanically
Hello world,
So, on -devel-announce, I mentioned:
* New testing distribution
This is a (mostly finished) project that will allow us
to test out distribution by making it sludgey rather
than frozen: that is, a new distribution is added between
[EMAIL PROTECTED] (Jason Gunthorpe) wrote on 14.08.00 in [EMAIL PROTECTED]:
On Mon, 14 Aug 2000, Joey Hess wrote:
You know, if apt could only support Reccommends, task packages could be
I don't care for this much, it breaks the model that apt-get follows, it
Well, I'd *very very much*
Drake Diedrich [EMAIL PROTECTED] wrote:
Under the Irix packaging system (quite nice UI except that it has to
handle Irix packages..) packages exist in a hierarchy, with lowest level
packages quite fine grained. For example:
I fw_bzip2 02/28/2000 bzip2-0.9.0c
Edward Betts writes:
Possible layout
~~~
snippage
I like the plan a lot. some thoughts:
doc/examples.tar.gz /usr/share/doc/examples/*
locale/*/gettext.tar.gz gettext translations
I wonder if the default docs should not go in a locale/ subdir for the
proper language
Decklin Foster [EMAIL PROTECTED] wrote:
I like the plan a lot. some thoughts:
Glade to hear it.
I wonder if the default docs should not go in a locale/ subdir for the
proper language (English for most of what exists now). I know very
little about i18b so I won't comment on the
Edward Betts [EMAIL PROTECTED] wrote:
How would it be implemented?
My recommendation would be one directory per package. Each subpackage could
just be part of a .tar.gz file. Having the binary dependent parts listed here
would imply that the package locate could
Bas Zoetekouw [EMAIL PROTECTED] writes:
I personally would like having hardware detection stuff in woody.
Wouldn't it be great to have to install procedure ask you something
like hi dude, I've detected that you've got a ne2000 NIC in your
computer. Shall I load the appropriate module?? (and
Thus spake Colin Walters ([EMAIL PROTECTED]):
I noticed the other day that recent versions of RedHat use something
called Kudzu (sp?) to do this. When I took out the network card, it
warned me that some hardware was missing, and offered to change some
things to compensate.
Has anyone has
On Wed, 16 Aug 2000, Bas Zoetekouw wrote:
Has anyone has looked into porting this [Kudzu] to Debian?
Mandrake, too, includes a hardware detection libarary (libdetect).
Some time ago, Dan Helfman [EMAIL PROTECTED] (Cc'ed him), was busy
packaging it. Dan, have you had any luck yet adapting
I recall reading a few months ago about a plan to merge ALL of the
existing hardware detection routines into one lump, in order to
consolidate work and effort. The proposal was met with acceptance by many
(if not all) of the major developers (Mandrake, Redhat, Suse, Turbo)
please post if
On Aug 16, Bas Zoetekouw wrote:
Mandrake, too, includes a hardware detection libarary (libdetect).
Some time ago, Dan Helfman [EMAIL PROTECTED] (Cc'ed him), was busy
packaging it. Dan, have you had any luck yet adapting it to Debian?
Dan has reasonably up-to-date packages of libdetect and
On Wed, Aug 16, 2000 at 08:46:38AM +0200, Bas Zoetekouw wrote:
Thus spake Colin Walters ([EMAIL PROTECTED]):
I noticed the other day that recent versions of RedHat use something
called Kudzu (sp?) to do this. When I took out the network card, it
warned me that some hardware was missing,
Christoph Martin wrote:
We have a problem with the bug tracking system as long as we can't
really find out to which versions of a package a bug really
applies. We only mosttimes have the version of the packages where a
problem showed up. But we don't know if the bug was introduced with
this
Anthony Towns wrote:
By omission, this does a fairly impressive injustice to everyone else
who helped with development, testing, fixing bugs, documenting problems
and work arounds, giving support, and everything else everyone's done
in the past months, so, well, thanks everyone!
Seconded!
On Mon, 14 Aug 2000, Joey Hess wrote:
* Tasks are great, but task-* packages suck when some of the
packages included have release critical bugs. (Remove the
package, the entire task breaks)
You know, if apt could only support Reccommends, task packages could be
a lot
Jason Gunthorpe wrote:
Tasks are bettered handled through some kind of non-package means. I've
long said we need to determine some kind of meta-package scheme (a
'package' whose only purpose is to logically group other packages).
How is introducing some basterdized form of package (perhaps
On Mon, Aug 14, 2000 at 10:55:59PM -0600, Jason Gunthorpe wrote:
Clearly the desired effect of all meta-packages is to provide the user
with a single node to manipulate and view a group of packages. They should
have special properties in any UI, you should be able to view and
manipulate
Drake Diedrich wrote:
Under the Irix packaging system (quite nice UI except that it has to
handle Irix packages..) packages exist in a hierarchy, with lowest level
packages quite fine grained.
Wow, I quite like this. How could we do it?
--
see shy jo
On Mon, Aug 14, 2000 at 10:12:38PM -0700, Joey Hess wrote:
The problem, as I see it, is that task packages declare a strong
dependency where often none really exists. After all, if it were a real
dependancy, we'd not be having this discussion, since aj/james/whoever's
course of action then
On Mon, 14 Aug 2000, Joey Hess wrote:
Jason Gunthorpe wrote:
Tasks are bettered handled through some kind of non-package means. I've
long said we need to determine some kind of meta-package scheme (a
'package' whose only purpose is to logically group other packages).
How is introducing
On Mon, 14 Aug 2000, Joey Hess wrote:
Drake Diedrich wrote:
Under the Irix packaging system (quite nice UI except that it has to
handle Irix packages..) packages exist in a hierarchy, with lowest level
packages quite fine grained.
Wow, I quite like this. How could we do it?
This is
Anthony Towns wrote:
Another way of doing might be to generate task packages as we have now
as part of dinstall, and install them into the archive. Another way
would be to not do this as part of dinstall, but on an autobuilder.
Well, if you're going to do that, what's stopping you from pulling
Jason Gunthorpe wrote:
Off hand, I would suspect you'd take an arbitary .deb and carve it into
sub packages internally - this is for effeciency.. Other debs can come
along and clealy install over the sub packages. Ex:
You have apt_1.1_i386.deb which contains
'doc'
'binary'
And
Joey Hess [EMAIL PROTECTED] writes:
Jason Gunthorpe wrote:
Tasks are bettered handled through some kind of non-package means. I've
long said we need to determine some kind of meta-package scheme (a
'package' whose only purpose is to logically group other packages).
How is
Marcelo E. Magallon wrote:
in the one bit you trimmed out, Jason said:
Er, no, I did not ignore that, nor did I trim all of it.
--
see shy jo
On Mon, Aug 14, 2000 at 11:08:59PM -0700, Joey Hess wrote:
Perhaps these sub-packages would be additional files in the ar file.
Perhaps those files themselves should be in .deb format? Then we have
sub package nesting and meta-data too
Of course this is all just off hand... :
Same.
On Tue, 15 Aug 2000, Anthony Towns wrote:
What I'd like to happen is basically be able to remove the package,
and just have the task automatically act as though that package had
never existed. Not complain in dselect about it, not worry people when
Apt gives you a warning, not do anything.
Thus spake Anthony Towns (aj@azure.humbug.org.au):
Once we get to woody, though, there are probably two things that are
particularly worthwhile doing. As per usual, we should probably have a few
weeks discussing release goals for woody to see what sort of direction
we want to head (and then
Anthony Towns writes:
* Working out which bugs are really release-critical and fixing
their severity so we know where we're at is overly time
consuming.
We have a problem with the bug tracking system as long as we can't
really find out to which versions of a package a
Today, Jason Gunthorpe [EMAIL PROTECTED] wrote:
The user should see a list of groups (I will call them this because I
think groupings can be more general than just tasks). The UI tool will
allow sorting and searching of the groups and when browsing individual
packages it will be possible to
[Please followup to -devel, since I do not yet subscribe to -boot]
On Tue, Aug 15, 2000 at 10:06:10AM +0200, Bas Zoetekouw wrote:
I personally would like having hardware detection stuff in woody.
This is something Progeny is attempting to accomplish for our version of
Debian later this year.
Hello world,
Well, as some of you might have noticed:
[EMAIL PROTECTED]:/org/ftp.debian.org/ftp/dists$ ls -l Debian2.2r0 stable
lrwxrwxrwx1 troupdebadmin6 Aug 14 13:06 Debian2.2r0 - stable
lrwxrwxrwx1 troupdebadmin6 Aug 14 13:06 stable - potato
CD images
53 matches
Mail list logo
