-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, 15 Aug 2013 23:48:46 -0500
Dennis Gilmore wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On Mon, 12 Aug 2013 14:47:03 +0100
> Richard Hughes wrote:
>
> > Hi all,
> >
> > I'd like to ask for comments on a feature I need for t
On Sat, Aug 17, 2013 at 5:15 PM, Dennis Gilmore wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On Sat, 17 Aug 2013 13:14:14 +0200
> drago01 wrote:
>
>> On Fri, Aug 16, 2013 at 6:48 AM, Dennis Gilmore
>> wrote:
>> > -BEGIN PGP SIGNED MESSAGE-
>> > Hash: SHA1
>> >
>> > On Mon
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sat, 17 Aug 2013 13:14:14 +0200
drago01 wrote:
> On Fri, Aug 16, 2013 at 6:48 AM, Dennis Gilmore
> wrote:
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA1
> >
> > On Mon, 12 Aug 2013 14:47:03 +0100
> > Richard Hughes wrote:
> >
> >> Hi all,
On Fri, Aug 16, 2013 at 6:48 AM, Dennis Gilmore wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On Mon, 12 Aug 2013 14:47:03 +0100
> Richard Hughes wrote:
>
>> Hi all,
>>
>> I'd like to ask for comments on a feature I need for the Fedora
>> Application Installer. The current yum back
I hope we can remain the rawhide packages for downgrade.
Any ideas?
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
On Fri, 16 Aug 2013 16:57:38 -0600
Kevin Fenzi wrote:
>
> Well, I think many folks won't like the extra disk space used.
More than likely, but if they are interested in testing maybe not.?
>
> I think it would take something like yum-plugin-local to have a
> proper repo that yum could see to
On Thu, 15 Aug 2013 22:46:10 +0100
Frank Murphy wrote:
> On Thu, 15 Aug 2013 15:15:11 -0600
> Kevin Fenzi wrote:
>
> > That sounds like it would be a lot of duplication in mirrormanager
> > and other parts of the project. ;)
> >
> > kevin
>
> Why not do it's on the users PC\Laptop. (As a cha
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mon, 12 Aug 2013 14:47:03 +0100
Richard Hughes wrote:
> Hi all,
>
> I'd like to ask for comments on a feature I need for the Fedora
> Application Installer. The current yum backend in PackageKit does
> something like this:
>
> * yum install foo
On Thu, 15 Aug 2013 15:15:11 -0600
Kevin Fenzi wrote:
> That sounds like it would be a lot of duplication in mirrormanager
> and other parts of the project. ;)
>
> kevin
Why not do it's on the users PC\Laptop. (As a change\feature?)
/etc/yum.repos.d/updates.repo (ditto testing if enabled)
keep
On Wed, 14 Aug 2013 18:22:34 -0500
Michael Cronenworth wrote:
> On 08/14/2013 12:26 PM, Kevin Fenzi wrote:
> > I guess I'm open to the idea, but I have long wished we could have
> > some way to always keep the previous version of a package for yum
> > downgrades. ;(
> >
> > Keeping all that in
Richard Hughes (hughsi...@gmail.com) said:
> On 12 August 2013 19:36, Bill Nottingham wrote:
> > I could see doing this, but it is a non-trivial change to how the
> > repositories are made, and there aren't really any resources assigned to
> > work on that. I can give some pointers to where and w
Le mercredi 14 août 2013 à 11:26 -0600, Kevin Fenzi a écrit :
> I guess I'm open to the idea, but I have long wished we could have some
> way to always keep the previous version of a package for yum
> downgrades. ;(
>
> Keeping all that in metadata would bloat it a lot.
I think Debian does that
On 13. 8. 2013 at 11:04:52, Chris Murphy wrote:
> What's the interval of repomd changes, daily? What approximate percentage of
> the entire repomd changes between day 1 and day 7? If the delta is
> comparatively small to full metadata files, what about implementing a daily
> repomd_delta sorta like
On Wed, 2013-08-14 at 11:24 -0600, Kevin Fenzi wrote:
> On Mon, 12 Aug 2013 11:07:43 -0400
> Mathieu Bridon wrote:
>
> ...snip...
>
> > It has an added benefit: it could make « yum downgrade » work better.
>
> This wouldn't work with yum downgrade would it? Doesn't yum downgrade
> need to 'see'
On 08/14/2013 12:26 PM, Kevin Fenzi wrote:
> I guess I'm open to the idea, but I have long wished we could have some
> way to always keep the previous version of a package for yum
> downgrades. ;(
>
> Keeping all that in metadata would bloat it a lot.
You could have an additional metadata packag
I guess I'm open to the idea, but I have long wished we could have some
way to always keep the previous version of a package for yum
downgrades. ;(
Keeping all that in metadata would bloat it a lot.
kevin
signature.asc
Description: PGP signature
--
devel mailing list
devel@lists.fedoraproject
On Mon, 12 Aug 2013 11:07:43 -0400
Mathieu Bridon wrote:
...snip...
> It has an added benefit: it could make « yum downgrade » work better.
This wouldn't work with yum downgrade would it? Doesn't yum downgrade
need to 'see' the packages in the metadata?
kevin
signature.asc
Description: PGP
What's the interval of repomd changes, daily? What approximate percentage of
the entire repomd changes between day 1 and day 7? If the delta is
comparatively small to full metadata files, what about implementing a daily
repomd_delta sorta like deltarpms?
I see both yum and dnf downloading large
On 12 August 2013 16:07, Mathieu Bridon wrote:
> In fact, how do you even know that there is a new package without
> downloading the new metadata?
We do download the new metadata, but in a temp "throwaway" location
(only the repomd and updateinfo) -- in an ideal world we'd have
something smaller
On 12 August 2013 19:36, Bill Nottingham wrote:
> I could see doing this, but it is a non-trivial change to how the
> repositories are made, and there aren't really any resources assigned to
> work on that. I can give some pointers to where and what would need changed,
> if you're interested in lo
Richard Hughes (hughsi...@gmail.com) said:
> Hi all,
>
> I'd like to ask for comments on a feature I need for the Fedora
> Application Installer. The current yum backend in PackageKit does
> something like this:
>
> * yum install foo
> * depsolve transaction using cached metadata
> * download fo
Hi,
On Monday, August 12, 2013 09:47 AM, Richard Hughes wrote:
So my proposal is thus:
1. We retain old packages on the mirrors for a minimum of 7 days.
2. We regenerate the metadata on every compose like before
3. We only include the latest package version in the metadata
4. If the user is ins
On Mon, Aug 12, 2013 at 02:47:03PM +0100, Richard Hughes wrote:
> appearing at odd times. So my proposal is thus:
[...]
> Comments welcome, thanks.
Sounds like like a good thing. Speaking as a former mirror admin, I'll
happily trade more storage for reduced bandwidth use.
--
Matthew Miller ☁☁☁
Hi all,
I'd like to ask for comments on a feature I need for the Fedora
Application Installer. The current yum backend in PackageKit does
something like this:
* yum install foo
* depsolve transaction using cached metadata
* download foo-0.1.noarch.rpm
* error! foo-0.1.noarch.rpm doesn't exist
* d
24 matches
Mail list logo
