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
debi
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
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
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 s
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 insid
> 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 im
>> Anthony Towns 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
be forced to take
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 side(r
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
On 18-Aug-00, 06:26 (CDT), Anthony Towns 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
something I've wanted to do f
Anthony Towns 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 to download six
>
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 bu
Anthony Towns 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 not sure how you'd bu
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 th
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
> bein
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
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 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
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 signat
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 c
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 implement
Edward Betts writes:
> Possible layout
> ~~~
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 (English
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 Compress/
[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
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 be
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 mechanical
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
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
> th
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
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
> 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
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 ad
On Tue, 15 Aug 2000, 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. For example:
[...]
>Many of our packages are already hierarchical ( x
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
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?"
[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. I
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
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
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 t
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
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... :>
>
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
>> 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).
>
> Ho
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'
>
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 pulli
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?
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 int
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
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: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
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 i
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
>
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!
53 matches
Mail list logo
