On 12/05/2009 06:22 AM, Orion Poplawski wrote:
On Fri, December 4, 2009 9:20 pm, Ralf Corsepius wrote:
On 12/03/2009 07:22 AM, Jesse Keating wrote:
On Thu, 2009-12-03 at 06:24 +0100, Ralf Corsepius wrote:
Yes, for people who are doing "full featured networked installs" w/
custom kickstart fil
On Fri, December 4, 2009 9:20 pm, Ralf Corsepius wrote:
> On 12/03/2009 07:22 AM, Jesse Keating wrote:
>> On Thu, 2009-12-03 at 06:24 +0100, Ralf Corsepius wrote:
>>> Yes, for people who are doing "full featured networked installs" w/
>>> custom kickstart files. I've never met such a person.
>>
>>
On 12/03/2009 07:22 AM, Jesse Keating wrote:
On Thu, 2009-12-03 at 06:24 +0100, Ralf Corsepius wrote:
People doing network installs can either add the updates repo to their
kickstart, or check the box in the anaconda UI, so that the updates
repos are considered at install time. No download of d
On Thu, 2009-12-03 at 06:24 +0100, Ralf Corsepius wrote:
> > People doing network installs can either add the updates repo to their
> > kickstart, or check the box in the anaconda UI, so that the updates
> > repos are considered at install time. No download of duplicate data.
> Yes, for people who
On Thu, 2009-12-03 at 06:51 +0100, Ralf Corsepius wrote:
> > We wouldn't be talking about removing the original GA set - just adding
> > updated pkgs into the path.
>
> Woa!!! With all due respect, but this would seem an stupid and silly
> plan to me.
The only way not to do that would be to mai
On 12/02/2009 09:12 PM, Kevin Kofler wrote:
> Seth Vidal wrote:
>> If you're looking for perfect division, sure - but the reality is this:
>>
>> 19K items in a single dir and ext3 and nfs and many many other things crap
>> themselves returning that list.
>>
>> If you make 36 subdirs (26+10) perform
On 12/03/2009 08:20 AM, Seth Vidal wrote:
>
>
> On Thu, 3 Dec 2009, Adam Williamson wrote:
>
>> On Thu, 2009-12-03 at 00:32 -0500, Seth Vidal wrote:
>>
>>> We wouldn't be talking about removing the original GA set - just adding
>>> updated pkgs into the path. So you'd still have the number of pk
On 12/03/2009 12:24 AM, Ralf Corsepius wrote:
> On 12/02/2009 06:40 PM, Jesse Keating wrote:
>> People doing network installs can either add the updates repo to their
>> kickstart, or check the box in the anaconda UI, so that the updates
>> repos are considered at install time. No download of dupl
On Thu, 2009-12-03 at 08:20 -0500, Seth Vidal wrote:
> >> We wouldn't be talking about removing the original GA set - just adding
> >> updated pkgs into the path. So you'd still have the number of pkgs -just
> >> all in one repo, that you have to download all of the metadata for all of
> >> the mo
On Dec 3, 2009, at 5:28, James Antill wrote:
On Thu, 2009-12-03 at 10:29 +0100, Nicolas Mailhot wrote:
Le Mer 2 décembre 2009 23:56, Matt Domsch a écrit :
On Wed, Dec 02, 2009 at 07:35:03PM +0100, Nicolas Mailhot wrote:
3. replace static mirrors with proxy-ing of kojipkgs.fedoraproject.o
I think that idea maybe isn't benefit with repository.
If updates repository is merged into Everything repository, Will metadata
files become too large? I know that the size of metadatas on updates and
everything are more than 30 megabytes. If these two repositories compose, We
will need download
On Thu, 2009-12-03 at 10:29 +0100, Nicolas Mailhot wrote:
>
> Le Mer 2 décembre 2009 23:56, Matt Domsch a écrit :
> >
> > On Wed, Dec 02, 2009 at 07:35:03PM +0100, Nicolas Mailhot wrote:
> >> 3. replace static mirrors with proxy-ing of kojipkgs.fedoraproject.org
> >> (make sure it works with web i
On Thu, 3 Dec 2009, Adam Williamson wrote:
On Thu, 2009-12-03 at 00:32 -0500, Seth Vidal wrote:
We wouldn't be talking about removing the original GA set - just adding
updated pkgs into the path. So you'd still have the number of pkgs -just
all in one repo, that you have to download all of t
Matt Domsch writes:
> We're at a point where 'ls in a directory' is becoming difficult even;
> you can't glob 15k package names in a shell.
Recent kernels have no argv limit any more.
Andreas.
--
Andreas Schwab, sch...@redhat.com
GPG Key fingerprint = D4E8 DBE3 3813 BB5D FA84 5EC7 45C6 250E
Le Mer 2 décembre 2009 23:56, Matt Domsch a écrit :
>
> On Wed, Dec 02, 2009 at 07:35:03PM +0100, Nicolas Mailhot wrote:
>> 3. replace static mirrors with proxy-ing of kojipkgs.fedoraproject.org
>> (make sure it works with web infrastructure instead of fighting it)
>
> Sorry, I don't understand t
* Adam Williamson [03/12/2009 10:10] :
>
> I don't think that was actually made clear in the initial proposal. I'd
> been assuming that the proposal was _exactly_ to remove the GA set.
No can do.
People who install from the netinst CD or do PXE installs without adding
the updates repo during the i
On Thu, 2009-12-03 at 00:32 -0500, Seth Vidal wrote:
> We wouldn't be talking about removing the original GA set - just adding
> updated pkgs into the path. So you'd still have the number of pkgs -just
> all in one repo, that you have to download all of the metadata for all of
> the more often,
Ralf Corsepius wrote:
Your concern is the bigger repodata?
My download of repodata towards the end of a release, or from rawhide,
is usually bigger than my download of packages. So yes, this would make
a difference. On the otherhand, there probably could be a repodiff that
would alleviate a l
On 12/03/2009 06:32 AM, Seth Vidal wrote:
On Thu, 3 Dec 2009, Ralf Corsepius wrote:
On 12/02/2009 07:09 PM, Seth Vidal wrote:
the merger of repos is already happening at the yum layer.
On the client's side - With a combined Everything+updates, this would
happen on the server side.
It's o
On Thu, 3 Dec 2009, Ralf Corsepius wrote:
On 12/02/2009 07:09 PM, Seth Vidal wrote:
the merger of repos is already happening at the yum layer.
On the client's side - With a combined Everything+updates, this would happen
on the server side.
It's one of the aspects which made me said "a c
On 12/02/2009 07:09 PM, Seth Vidal wrote:
the merger of repos is already happening at the yum layer.
On the client's side - With a combined Everything+updates, this would
happen on the server side.
It's one of the aspects which made me said "a combined
Everything+updates shifts costs from
On 12/02/2009 06:40 PM, Jesse Keating wrote:
On Wed, 2009-12-02 at 18:09 +0100, Ralf Corsepius wrote:
* It shifts "costs" from "users" to "vendor"
and from "mirrors" to "master".
* It helps users who are using networked installs to spare bandwidth
(avoids downloading obsolete packages from "Eve
On Wed, 2 Dec 2009, Bruno Wolff III wrote:
> On Wed, Dec 02, 2009 at 17:58:24 -0500,
> Seth Vidal wrote:
> >
> > I tested it on our backend to be sure. getting the complete pkglist
> > goes from taking 5 minutes to take 30s.
> >
> > yes, I said 5 minutes.
>
> Have you tried any of the tunning k
On Wed, Dec 02, 2009 at 12:01:49PM -0500, Casey Dahlin wrote:
>
>You owe me $5.
It hasn't been a week and you haven't sent me your address.
I did notice though, so keep up the good work ;)
josh
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinf
On Thu, 3 Dec 2009, Kevin Kofler wrote:
Seth Vidal wrote:
If you're looking for perfect division, sure - but the reality is this:
19K items in a single dir and ext3 and nfs and many many other things crap
themselves returning that list.
If you make 36 subdirs (26+10) performance gets DRAMAT
Seth Vidal wrote:
> If you're looking for perfect division, sure - but the reality is this:
>
> 19K items in a single dir and ext3 and nfs and many many other things crap
> themselves returning that list.
>
> If you make 36 subdirs (26+10) performance gets DRAMATICALLY better for
> producing the
On Wed, 2 Dec 2009, Bruno Wolff III wrote:
On Wed, Dec 02, 2009 at 17:58:24 -0500,
Seth Vidal wrote:
I tested it on our backend to be sure. getting the complete pkglist
goes from taking 5 minutes to take 30s.
yes, I said 5 minutes.
Have you tried any of the tunning knobs to have the dir
On Wed, Dec 02, 2009 at 17:58:24 -0500,
Seth Vidal wrote:
>
> I tested it on our backend to be sure. getting the complete pkglist
> goes from taking 5 minutes to take 30s.
>
> yes, I said 5 minutes.
Have you tried any of the tunning knobs to have the directory cache be
alotted more space or g
On Wed, Dec 02, 2009 at 03:08:06PM -0800, Jesse Keating wrote:
> On Wed, 2009-12-02 at 16:58 -0600, Matt Domsch wrote:
> > On Wed, Dec 02, 2009 at 11:09:41AM -0500, Bill Nottingham wrote:
> > > The separate Everything tree that does not get obsoleted is required
> > > in some form for GPL complianc
On Wed, 2009-12-02 at 16:58 -0600, Matt Domsch wrote:
> On Wed, Dec 02, 2009 at 11:09:41AM -0500, Bill Nottingham wrote:
> > The separate Everything tree that does not get obsoleted is required
> > in some form for GPL compliance, with respect to the ISO images that
> > we ship. Any new solution wo
On 12/02/2009 06:05 PM, James Antill wrote:
> On Wed, 2009-12-02 at 17:46 -0500, Peter Jones wrote:
>> so that every directory has about the same number of things.
>
> This should be fairly easy to code, but has a big downside:
>
> Packages will move directories.
>
> 1. This will upset
On Wed, 2009-12-02 at 17:46 -0500, Peter Jones wrote:
> (on my on tangent...)
>
> On 12/02/2009 12:48 PM, Jesse Keating wrote:
> > I hypothesize that we could place all rpms for a given release
> > in a single directory (seth will hate this as he wants to split them up
> > based on first letter of
On Wed, 2 Dec 2009, Peter Jones wrote:
On 12/02/2009 05:58 PM, Seth Vidal wrote:
On Wed, 2 Dec 2009, Peter Jones wrote:
On 12/02/2009 03:53 PM, Seth Vidal wrote:
On Wed, 2 Dec 2009, Nicolas Mailhot wrote:
3. replace static mirrors with proxy-ing of kojipkgs.fedoraproject.org
(make sure
On 12/02/2009 05:58 PM, Seth Vidal wrote:
>
>
> On Wed, 2 Dec 2009, Peter Jones wrote:
>
>> (on my on tangent...)
>>
>> On 12/02/2009 12:48 PM, Jesse Keating wrote:
>>> I hypothesize that we could place all rpms for a given release
>>> in a single directory (seth will hate this as he wants to sp
On 12/02/2009 05:58 PM, Seth Vidal wrote:
>
>
> On Wed, 2 Dec 2009, Peter Jones wrote:
>
>> On 12/02/2009 03:53 PM, Seth Vidal wrote:
>>> On Wed, 2 Dec 2009, Nicolas Mailhot wrote:
3. replace static mirrors with proxy-ing of kojipkgs.fedoraproject.org
(make sure it works with web infra
On Wed, 2 Dec 2009, Peter Jones wrote:
On 12/02/2009 03:53 PM, Seth Vidal wrote:
On Wed, 2 Dec 2009, Nicolas Mailhot wrote:
3. replace static mirrors with proxy-ing of kojipkgs.fedoraproject.org
(make sure it works with web infrastructure instead of fighting it)
I don't think that would wo
On Wed, Dec 02, 2009 at 11:09:41AM -0500, Bill Nottingham wrote:
> The separate Everything tree that does not get obsoleted is required
> in some form for GPL compliance, with respect to the ISO images that
> we ship. Any new solution would have to preserve this.
? We provide Fedora-*-source-disc
On Wed, 2 Dec 2009, Peter Jones wrote:
(on my on tangent...)
On 12/02/2009 12:48 PM, Jesse Keating wrote:
I hypothesize that we could place all rpms for a given release
in a single directory (seth will hate this as he wants to split them up
based on first letter of their name for better file
On Wed, Dec 02, 2009 at 07:35:03PM +0100, Nicolas Mailhot wrote:
> 3. replace static mirrors with proxy-ing of kojipkgs.fedoraproject.org
> (make sure it works with web infrastructure instead of fighting it)
Sorry, I don't understand this. Can you elaborate? That would help
me scope the impact t
On Wed, Dec 02, 2009 at 02:03:51PM -0800, Jesse Keating wrote:
> On Wed, 2009-12-02 at 15:52 -0500, Seth Vidal wrote:
> > Isn't this, eventually, what the packagedb is supposed to be able to
> > do?
>
> I gather it's a "ls in a directory" kind of thing, not an interface to
> one tool or another ki
On 12/02/2009 03:53 PM, Seth Vidal wrote:
> On Wed, 2 Dec 2009, Nicolas Mailhot wrote:
>> 3. replace static mirrors with proxy-ing of kojipkgs.fedoraproject.org
>> (make sure it works with web infrastructure instead of fighting it)
>
> I don't think that would work fine with a lot of our mirrors.
On 12/02/2009 05:03 PM, Jesse Keating wrote:
> On Wed, 2009-12-02 at 15:52 -0500, Seth Vidal wrote:
>> Isn't this, eventually, what the packagedb is supposed to be able to
>> do?
>
> I gather it's a "ls in a directory" kind of thing, not an interface to
> one tool or another kind of thing. But I
(on my on tangent...)
On 12/02/2009 12:48 PM, Jesse Keating wrote:
> I hypothesize that we could place all rpms for a given release
> in a single directory (seth will hate this as he wants to split them up
> based on first letter of their name for better filesystem performance),
Ugh, first letter
Dne 2.12.2009 17:06, Josh Boyer napsal(a):
However, other than 'browsing manually for packages', I'm not really
sure what problem you are trying to solve by getting rid of the
updates repository. It would seem like this has quite a bit of cost
for relatively little to no real gain?
I am usuall
On Wed, 2009-12-02 at 15:52 -0500, Seth Vidal wrote:
> Isn't this, eventually, what the packagedb is supposed to be able to
> do?
I gather it's a "ls in a directory" kind of thing, not an interface to
one tool or another kind of thing. But I could be wrong.
--
Jesse Keating
Fedora -- Freedom² i
On Wed, 2 Dec 2009, Nicolas Mailhot wrote:
Since people are posting wishes, here is mine:
1. stop shuffling packages from directory to directory as they get
promoted/demoted from release to release
we sort of do this now with hardlinks - the problem is when we have to
resign the pkgs.
On Wed, 2 Dec 2009, Jesse Keating wrote:
On Wed, 2009-12-02 at 13:09 -0500, Seth Vidal wrote:
I guess what I don't see is what the net benefit is here.
From what I can gather...
A) a single path to look at when manually looking for rpms.
Isn't this, eventually, what the packagedb is supp
Once upon a time, Matthew Booth said:
> The separate updates directory has been a pain for as long as I've been
> using RHL/Fedora Core/Fedora. It means you have two places to look when
> searching for packages manually, and twice as much to configure when
> you're configuring yum.
Are these r
Since people are posting wishes, here is mine:
1. stop shuffling packages from directory to directory as they get
promoted/demoted from release to release
2. have a single authoritative URL for each package
3. replace static mirrors with proxy-ing of kojipkgs.fedoraproject.org
(make sure it work
On Wed, 2009-12-02 at 13:09 -0500, Seth Vidal wrote:
> I guess what I don't see is what the net benefit is here.
From what I can gather...
A) a single path to look at when manually looking for rpms.
B) only one config entry to mess with when modifying repos for a release
(my alternate proposal d
On Wed, 2 Dec 2009, Jesse Keating wrote:
On Wed, 2009-12-02 at 14:39 +, Matthew Booth wrote:
The separate updates directory has been a pain for as long as I've been
using RHL/Fedora Core/Fedora. It means you have two places to look when
searching for packages manually, and twice as much t
On Wed, 2009-12-02 at 17:58 +, Matthew Booth wrote:
> The GA package could be kept around as a separate, static repo nobody
> uses under normal circumstances. Combining GA+updates into a single repo
> would not consume additional bandwidth for anybody at all, and only
> testers would have to
On Wed, 2009-12-02 at 11:06 -0500, Josh Boyer wrote:
> so it's certainly a technical possibility. It does have implications
> though. Off the top of my head, I can think of:
>
> 1) Composing a new everything tree for updates would lead to larger
> compose times. That could possibly mean that g
On Wed, 2 Dec 2009, James Cassell wrote:
On Wed, 02 Dec 2009 12:47:17 -0500, Matthew Booth wrote:
So, create a meta-repo that just says "I'm the combination of these several
repos over here"? Of course, it'd require modification of all the programs
that know how to talk to repos...
On Wed, Dec 02, 2009 at 05:47:17PM +, Matthew Booth wrote:
> On 02/12/09 16:06, Josh Boyer wrote:
> >On Wed, Dec 02, 2009 at 03:44:08PM +, Matthew Booth wrote:
> >>On 02/12/09 15:26, Josh Boyer wrote:
> >>>On Wed, Dec 02, 2009 at 02:39:30PM +, Matthew Booth wrote:
> The separate upd
On 02/12/09 17:40, Jesse Keating wrote:
On Wed, 2009-12-02 at 18:09 +0100, Ralf Corsepius wrote:
* It shifts "costs" from "users" to "vendor"
and from "mirrors" to "master".
* It helps users who are using networked installs to spare bandwidth
(avoids downloading obsolete packages from "Everythi
On Wed, 02 Dec 2009 12:47:17 -0500, Matthew Booth
wrote:
Any tool which deals with repositories requires the repo to be
configured twice. Off the top of my head I can think of:
1. yum
separate repo and updates-repo in yum.conf.
2. livecd tools
two repos in kickstart
3. revisor
On Wed, 2009-12-02 at 14:39 +, Matthew Booth wrote:
> The separate updates directory has been a pain for as long as I've been
> using RHL/Fedora Core/Fedora. It means you have two places to look when
> searching for packages manually, and twice as much to configure when
> you're configuring
On 02/12/09 16:06, Josh Boyer wrote:
On Wed, Dec 02, 2009 at 03:44:08PM +, Matthew Booth wrote:
On 02/12/09 15:26, Josh Boyer wrote:
On Wed, Dec 02, 2009 at 02:39:30PM +, Matthew Booth wrote:
The separate updates directory has been a pain for as long as I've been
using RHL/Fedora Core/
On Wed, Dec 2, 2009 at 5:37 PM, Matthew Booth wrote:
>
> That's not a bug, it's a feature! Seriously, wasn't it a specific F10 or F11
> feature that anaconda allowed the user to specify that updates be installed
> at installation time? Certainly I used to have Debianites crow at me that my
> insta
On Wed, 2009-12-02 at 18:09 +0100, Ralf Corsepius wrote:
>
> * It shifts "costs" from "users" to "vendor"
> and from "mirrors" to "master".
> * It helps users who are using networked installs to spare bandwidth
> (avoids downloading obsolete packages from "Everything"/"Fedora").
>
> Admitted, fo
On 02/12/09 16:09, Bill Nottingham wrote:
Matthew Booth (mbo...@redhat.com) said:
The separate updates directory has been a pain for as long as I've
been using RHL/Fedora Core/Fedora. It means you have two places to
look when searching for packages manually, and twice as much to
configure when y
On Wed, 2009-12-02 at 14:39 +, Matthew Booth wrote:
> The separate updates directory has been a pain for as long as I've been
> using RHL/Fedora Core/Fedora. It means you have two places to look when
> searching for packages manually, and twice as much to configure when
> you're configuring
On 02/12/09 16:01, Justin M. Forbes wrote:
On Wed, Dec 02, 2009 at 02:39:30PM +, Matthew Booth wrote:
The separate updates directory has been a pain for as long as I've been
using RHL/Fedora Core/Fedora. It means you have two places to look when
searching for packages manually, and twice as
On 12/02/2009 06:01 PM, Casey Dahlin wrote:
On Wed, Dec 02, 2009 at 11:06:22AM -0500, Josh Boyer wrote:
However, other than 'browsing manually for packages', I'm not really
sure what problem you are trying to solve by getting rid of the
updates repository. It would seem like this has quite a
On Wed, 2 Dec 2009, Paul W. Frields wrote:
On Wed, Dec 02, 2009 at 11:09:41AM -0500, Bill Nottingham wrote:
we ship. Any new solution would have to preserve this.
Might there also be export compliance implications too?
A larger isssue is constantly having the repodata for the everything
On Wed, Dec 02, 2009 at 11:06:22AM -0500, Josh Boyer wrote:
> 1) Composing a new everything tree for updates would lead to larger
> compose times. That could possibly mean that getting updates out would
> take > 1 day per 'push'. We've been trying to improve updates push
> times so it would be a
On Wed, Dec 02, 2009 at 11:28:24AM -0500, Paul W. Frields wrote:
> >
> > The separate Everything tree that does not get obsoleted is required
> > in some form for GPL compliance, with respect to the ISO images that
> > we ship. Any new solution would have to preserve this.
>
> Might there also be
Ralf Corsepius (rc040...@freenet.de) said:
> Does the FSF/GPL demand to keep a repo around for ISOs?
> A "rolling Everything" would not touch the ISOs. They would still be around.
The LiveCD/spins satisfy their source requirements via the source
repositories; they do not compose separate live sou
On 12/02/2009 05:32 PM, Kevin Fenzi wrote:
On Wed, 02 Dec 2009 17:27:17 +0100
Ralf Corsepius wrote:
On 12/02/2009 05:09 PM, Bill Nottingham wrote:
Matthew Booth (mbo...@redhat.com) said:
The separate updates directory has been a pain for as long as I've
been using RHL/Fedora Core/Fedora. It
On Wed, 02 Dec 2009 17:27:17 +0100
Ralf Corsepius wrote:
> On 12/02/2009 05:09 PM, Bill Nottingham wrote:
> > Matthew Booth (mbo...@redhat.com) said:
> >> The separate updates directory has been a pain for as long as I've
> >> been using RHL/Fedora Core/Fedora. It means you have two places to
> >
On Wed, Dec 02, 2009 at 11:09:41AM -0500, Bill Nottingham wrote:
> Matthew Booth (mbo...@redhat.com) said:
> > The separate updates directory has been a pain for as long as I've
> > been using RHL/Fedora Core/Fedora. It means you have two places to
> > look when searching for packages manually, an
On 12/02/2009 05:09 PM, Bill Nottingham wrote:
Matthew Booth (mbo...@redhat.com) said:
The separate updates directory has been a pain for as long as I've
been using RHL/Fedora Core/Fedora. It means you have two places to
look when searching for packages manually, and twice as much to
configure w
On Wed, Dec 02, 2009 at 10:01:51AM -0600, Justin M. Forbes wrote:
> On Wed, Dec 02, 2009 at 02:39:30PM +, Matthew Booth wrote:
> > The separate updates directory has been a pain for as long as I've been
> > using RHL/Fedora Core/Fedora. It means you have two places to look when
> > searching
2009/12/2 Justin M. Forbes
> The only downside to merging updates into the main repository...
I would also assume that the repo data will need to be regenerated and often
be much larger than the one that is for the updates only repository, so
there will be acost to end users with this proposed
Matthew Booth (mbo...@redhat.com) said:
> The separate updates directory has been a pain for as long as I've
> been using RHL/Fedora Core/Fedora. It means you have two places to
> look when searching for packages manually, and twice as much to
> configure when you're configuring yum. It has never
On Wed, Dec 02, 2009 at 03:44:08PM +, Matthew Booth wrote:
> On 02/12/09 15:26, Josh Boyer wrote:
>> On Wed, Dec 02, 2009 at 02:39:30PM +, Matthew Booth wrote:
>>> The separate updates directory has been a pain for as long as I've been
>>> using RHL/Fedora Core/Fedora. It means you have two
On Wed, Dec 02, 2009 at 02:39:30PM +, Matthew Booth wrote:
> The separate updates directory has been a pain for as long as I've been
> using RHL/Fedora Core/Fedora. It means you have two places to look when
> searching for packages manually, and twice as much to configure when you're
> confi
Josh Boyer wrote:
On Wed, Dec 02, 2009 at 09:00:53AM -0600, Jon Ciesla wrote:
Matthew Booth wrote:
The separate updates directory has been a pain for as long as I've
been using RHL/Fedora Core/Fedora. It means you have two places to
look when searching for packages manually, and twic
On 02/12/09 15:26, Josh Boyer wrote:
On Wed, Dec 02, 2009 at 02:39:30PM +, Matthew Booth wrote:
The separate updates directory has been a pain for as long as I've been
using RHL/Fedora Core/Fedora. It means you have two places to look when
searching for packages manually, and twice as much t
On Wed, Dec 02, 2009 at 02:39:30PM +, Matthew Booth wrote:
> The separate updates directory has been a pain for as long as I've been
> using RHL/Fedora Core/Fedora. It means you have two places to look when
> searching for packages manually, and twice as much to configure when
> you're co
On Wed, Dec 02, 2009 at 09:00:53AM -0600, Jon Ciesla wrote:
> Matthew Booth wrote:
>> The separate updates directory has been a pain for as long as I've
>> been using RHL/Fedora Core/Fedora. It means you have two places to
>> look when searching for packages manually, and twice as much to
>>
On 12/02/2009 10:30 AM, Jon Ciesla wrote:
Matthew Booth wrote:
The separate updates directory has been a pain for as long as I've
been using RHL/Fedora Core/Fedora. It means you have two places to
look when searching for packages manually, and twice as much to
configure when you're configuring y
On 12/02/2009 03:39 PM, Matthew Booth wrote:
The separate updates directory has been a pain for as long as I've been
using RHL/Fedora Core/Fedora. It means you have two places to look when
searching for packages manually, and twice as much to configure when
you're configuring yum. It has never be
Matthew Booth wrote:
The separate updates directory has been a pain for as long as I've
been using RHL/Fedora Core/Fedora. It means you have two places to
look when searching for packages manually, and twice as much to
configure when you're configuring yum. It has never benefitted me, or
anybo
The separate updates directory has been a pain for as long as I've been
using RHL/Fedora Core/Fedora. It means you have two places to look when
searching for packages manually, and twice as much to configure when
you're configuring yum. It has never benefitted me, or anybody I know,
but it has
86 matches
Mail list logo
