[Yum-devel] Yum-devel Digest, Vol 63, Issue 3

Wed Sep 23 17:06:57 UTC 2009

Hello Folks,

 I had sent an email sometime back, regarding NOT being able to repo's package directory in yum-3.2.22.

    James Antill had replied back with 2 options below.

    In the email below, you have mentioned 
    1) For just a local hack, you could just still override the '_dir_setup_pkgdir' value. 
    Qs-->> How can I do this in YUM plugin.
    2) If you want it to be writable again, it's possible but a bit of work, open
    an RFE ticket in BZ or trac.
    Qs--->>> Has this been already fixed in newer version of YUM. Please let me know, if this issue is still there.
    Thanks,

    Sudha

--- On Thu, 6/4/09, yum-devel-request at lists.baseurl.org <yum-devel-request at lists.baseurl.org> wrote:

From: yum-devel-request at lists.baseurl.org <yum-devel-request at lists.baseurl.org>
Subject: Yum-devel Digest, Vol 63, Issue 3
To: yum-devel at lists.baseurl.org
Date: Thursday, June 4, 2009, 12:00 PM

Send Yum-devel mailing list submissions to
    yum-devel at lists.baseurl.org

To subscribe or unsubscribe via the World Wide Web, visit
    http://lists.baseurl.org/mailman/listinfo/yum-devel
or, via email, send a message with subject or body 'help' to
    yum-devel-request at lists.baseurl.org

You can reach the person managing the list at
    yum-devel-owner at lists.baseurl.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Yum-devel digest..."

Today's Topics:

   1. Re: Unable to set repo attribute pkgdir, using YUM Plugin
      (James Antill)
   2. Re: group DB (Florian Festi)

----------------------------------------------------------------------

Message: 1
Date: Wed, 03 Jun 2009 09:37:55 -0400
From: James Antill <james at fedoraproject.org>
Subject: Re: [Yum-devel] Unable to set repo attribute pkgdir, using
    YUM Plugin
To: yum development <yum-devel at lists.baseurl.org>
Message-ID: <1244036275.18685.73.camel at code.and.org>
Content-Type: text/plain

On Tue, 2009-06-02 at 17:33 -0700, Creative Innovative wrote:
> Hi Folks,
> 
> I am using yum-3.2.22 version.
> 
> I have modified the downloadonly.py YUM plugin, that comes with
> yum-utils.
> 
> def postreposetup_hook(conduit):
>     package_mailbox = conduit.confString('main', 'package_mailbox',
> '/var/pkg_mailbox')
>     print 'setting pkgdir=%s' % package_mailbox
>     repos = conduit.getRepos();
>     list = repos.listEnabled();
> 
>     for repo in list:
>         repo.setAttribute('pkgdir', package_mailbox)
> 
> When the above plugin runs, it quits with below error,

Yes, it was changed in commit cea34c86cc5142effa3b33fce1a62dff1d8d2bc0.
It was generally assumed to be a readonly attribute. For just a local
hack, you could just still override the '_dir_setup_pkgdir' value. If
you want it to be writable again, it's possible but a bit of work, open
an RFE ticket in BZ or trac.

-- 
James Antill <james at fedoraproject.org>
Fedora

------------------------------

Message: 2
Date: Wed, 03 Jun 2009 17:33:00 +0200
From: Florian Festi <ffesti at redhat.com>
Subject: Re: [Yum-devel] group DB
To: yum development <yum-devel at lists.baseurl.org>
Message-ID: <4A2697AC.8030808 at redhat.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Hi everybody!

I very much appreciate the effort to improve the handling of groups in 
yum. Nevertheless I think this effort is too short sighted. The 
mechanisms we use to handle packages still date back to the time where 
Fedora  had 1500 packages. We've see a growth (in number of packages) by 
a factor ten since then and I expect another factor ten soonish. I 
belief it is time to sit back and rethink the whole package selection 
topic from the beginning. And while better "group" (what ever this 
means) handling will be part of it it surely will not be sufficient to 
solve the problems we are currently running into.

Right now we mix several things in the comps groups:

1. Grouping similar thing so users can select the ones he likes (Office 
applications, Browsers, Games, ...)
2. Preselected installation patterns with one of each kind (GNOME, KDE)
3. Offer related packages that the user might also be interested.
4. Hide packages that the user is most likely not interested in (libs, 
system core)
5. Add a more powerful selection layer (conditionals - mainly for 
language support) (anaconda only)

Additionally to mixing thinks up comps is not scaling with the number of 
packages.
Right now we only have 64 groups (when not counting the language 
groups). This is simply not enough to structure 10k packages and surely 
not enough for 100k. So IMHO we need to think how we can further 
decentralize the grouping process and encourage people  to take care of 
special application domains.

Another area of great pain is language support. There are hundreds of 
packages waiting to be split up by language if there only was a way to 
handle the huge amount of new sub packages (yes, we'll reach the 100k 
packages much faster if this happens).

Another thing that has been silently shifting is the ration between the 
distribution and the typical installation. While it used to be 
(guessing) 800/1500 it is now 1500/15000. The burden of the meta data is 
getting heavier and heavier compared to the actual install data. This is 
probably not becoming critical soon but something we should keep an eye on.

But back to the package selection: IMHO we need to reinvent and 
reimplement the package selection from scratch within the next two years 
- the earlier the better. First step should be collecting all the use 
cases and finding out what level of control is desirable for the 
different meta data pieces.

Florian

------------------------------

_______________________________________________
Yum-devel mailing list
Yum-devel at lists.baseurl.org
http://lists.baseurl.org/mailman/listinfo/yum-devel

End of Yum-devel Digest, Vol 63, Issue 3
****************************************

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.baseurl.org/pipermail/yum-devel/attachments/20090923/1b04b82c/attachment-0001.htm>