4:57 a.m.
I see that the Edit->Repository menu item is not yet implemented till
Pirut 1.3.8. I am going to write one for the offline package
management tool (http://fedoraproject.org/wiki/DebarshiRay/rum) I am
making for this year's Summer of Code
(http://fedoraproject.org/wiki/SummerOfCode/2007/DebarshiRay).
Do you already have some plans or suggestions in mind regarding the
design and/or functionality of Edit->Repository that I can base my
work on? Otherwise I can create one which will benefit both Pirut and
my application.
Thanks,
Debarshi
--
GPG key ID: 63D4A5A7
Key server: pgp.mit.edu
7:05 a.m.
On Mon, 2007-07-02 at 15:27 +0530, Debarshi 'Rishi' Ray wrote:
I see that the Edit->Repository menu item is not yet implemented
till
Pirut 1.3.8. I am going to write one for the offline package
management tool (http://fedoraproject.org/wiki/DebarshiRay/rum) I am
making for this year's Summer of Code
(http://fedoraproject.org/wiki/SummerOfCode/2007/DebarshiRay).
Do you already have some plans or suggestions in mind regarding the
design and/or functionality of Edit->Repository that I can base my
work on? Otherwise I can create one which will benefit both Pirut and
my application.
one already exists. Look up 'repoman'.
-sv
7:16 a.m.
Debarshi 'Rishi' Ray wrote:
I see that the Edit->Repository menu item is not yet implemented
till
Pirut 1.3.8. I am going to write one for the offline package
management tool (http://fedoraproject.org/wiki/DebarshiRay/rum) I am
making for this year's Summer of Code
(http://fedoraproject.org/wiki/SummerOfCode/2007/DebarshiRay).
Do you already have some plans or suggestions in mind regarding the
design and/or functionality of Edit->Repository that I can base my
work on? Otherwise I can create one which will benefit both Pirut and
my application.
Thanks,
Debarshi
I have also created a 'system-config-repositories' tool to edit
repositories, feel free to use any code you like.
http://tim.yum-extender.org/blog/2007/02/12/yum-repository-configuration-...
http://yumex.svn.sourceforge.net/viewvc/yumex/trunk/system-config-repo/
Tim
7:26 a.m.
Thanks.
By the way is there any decision on whether Pirut should have the
"configure repository" functionality, or it should be restricted to
repoman or system-config-repositories?
Thanks,
Debarshi
--
GPG key ID: 63D4A5A7
Key server: pgp.mit.edu
9:42 a.m.
On Mon, 2007-07-02 at 15:27 +0530, Debarshi 'Rishi' Ray wrote:
I see that the Edit->Repository menu item is not yet implemented
till
Pirut 1.3.8. I am going to write one for the offline package
management tool (http://fedoraproject.org/wiki/DebarshiRay/rum) I am
making for this year's Summer of Code
(http://fedoraproject.org/wiki/SummerOfCode/2007/DebarshiRay).
Do you already have some plans or suggestions in mind regarding the
design and/or functionality of Edit->Repository that I can base my
work on? Otherwise I can create one which will benefit both Pirut and
my application.
There's definitely need to flesh out and actually have the menu item in
pirut be useful. There's already some code in various places (repoman
and system-config-repositories in yumex are standalone... I think
there's also some code in revisor). But I'm not all that sold on the UI
with either...
I think the place to start is with writing up some use cases and then
trying to do some mockups from there before ever writing any code.
Then the tricky part is likely to be doing the config reading/writing in
a way that's not lossy. repoman actually has a good start on some of
this, but it'd be nice to actually work towards getting that code into
yum itself so that every tool doesn't have to re-invent those bits.
Jeremy
10 a.m.
On Mon, 2007-07-02 at 10:42 -0400, Jeremy Katz wrote:
On Mon, 2007-07-02 at 15:27 +0530, Debarshi 'Rishi' Ray
wrote:
> I see that the Edit->Repository menu item is not yet implemented till
> Pirut 1.3.8. I am going to write one for the offline package
> management tool (http://fedoraproject.org/wiki/DebarshiRay/rum) I am
> making for this year's Summer of Code
> (http://fedoraproject.org/wiki/SummerOfCode/2007/DebarshiRay).
>
> Do you already have some plans or suggestions in mind regarding the
> design and/or functionality of Edit->Repository that I can base my
> work on? Otherwise I can create one which will benefit both Pirut and
> my application.
There's definitely need to flesh out and actually have the menu item in
pirut be useful. There's already some code in various places (repoman
and system-config-repositories in yumex are standalone... I think
there's also some code in revisor). But I'm not all that sold on the UI
with either...
I think the place to start is with writing up some use cases and then
trying to do some mockups from there before ever writing any code.
Then the tricky part is likely to be doing the config reading/writing in
a way that's not lossy. repoman actually has a good start on some of
this, but it'd be nice to actually work towards getting that code into
yum itself so that every tool doesn't have to re-invent those bits.
that's fine - provided we aren't pulling in the gui portion of repoman.
I have no interest in dragging along gtk bits in/around yum.
-sv
4:33 a.m.
> Then the tricky part is likely to be doing the config
reading/writing in
> a way that's not lossy. repoman actually has a good start on some of
> this, but it'd be nice to actually work towards getting that code into
> yum itself so that every tool doesn't have to re-invent those bits.
that's fine - provided we aren't pulling in the gui portion
of repoman.
I have no interest in dragging along gtk bits in/around yum.
I think Jeremy was taking about an interface, similar to
Repository.enable/disable and RepoStorage.enableRepo/disableRepo,
which will do the file handling.
Happy hacking,
Debarshi
--
GPG key ID: 63D4A5A7
Key server: pgp.mit.edu
12:38 p.m.
Jeremy Katz wrote:
On Mon, 2007-07-02 at 15:27 +0530, Debarshi 'Rishi' Ray
wrote:
> I see that the Edit->Repository menu item is not yet implemented till
> Pirut 1.3.8. I am going to write one for the offline package
> management tool (http://fedoraproject.org/wiki/DebarshiRay/rum) I am
> making for this year's Summer of Code
> (http://fedoraproject.org/wiki/SummerOfCode/2007/DebarshiRay).
>
> Do you already have some plans or suggestions in mind regarding the
> design and/or functionality of Edit->Repository that I can base my
> work on? Otherwise I can create one which will benefit both Pirut and
> my application.
>
There's definitely need to flesh out and actually have the menu item in
pirut be useful. There's already some code in various places (repoman
and system-config-repositories in yumex are standalone... I think
there's also some code in revisor). But I'm not all that sold on the UI
with either...
I think the place to start is with writing up some use cases and then
trying to do some mockups from there before ever writing any code.
Then the tricky part is likely to be doing the config reading/writing in
a way that's not lossy. repoman actually has a good start on some of
this, but it'd be nice to actually work towards getting that code into
yum itself so that every tool doesn't have to re-invent those bits.
Jeremy
Sounds like a good idea, the config write routine in yum will remove all
the # comment lines and mix all the options.
I fixed the mixing in system-config-repo by building a extra layer on
the yum config API, but it don't take care off the # comments.
I would be a good idea to teach yum to save config files, without losing
information.
Tim
9:23 a.m.
Tim Lauridsen wrote:
>
Sounds like a good idea, the config write routine in yum will remove all
the # comment lines and mix all the options.
I fixed the mixing in system-config-repo by building a extra layer on
the yum config API, but it don't take care off the # comments.
I would be a good idea to teach yum to save config files, without losing
information.
This might be a good time to rethink whether Pirut and YumEx should be
merged together. Recent YumEx changes have made it look more and more
like Pirut and Pirut is started to grow more features similar to YumEx.
Looks like they are converging to me. Any reasons not to merge?
Rahul
11:04 a.m.
https://fedoraproject.org/wiki/Usability/Objectives/Pirut
There are some designs already available on the above link. Can I have
a look at the source code used to create them?
Thanks,
Debarshi
--
GPG key ID: 63D4A5A7
Key server: pgp.mit.edu
11:16 a.m.
Debarshi 'Rishi' Ray wrote:
https://fedoraproject.org/wiki/Usability/Objectives/Pirut
There are some designs already available on the above link. Can I have
a look at the source code used to create them?
I remember Thomas blogging about this long back. Don't think the changes
were submitted back.
Contact https://fedoraproject.org/wiki/ThomasCanniot
Rahul
11:21 a.m.
I had CC'ed him in the previous mail. :-)
Regards,
Debarshi
--
GPG key ID: 63D4A5A7
Key server: pgp.mit.edu
11:32 a.m.
Debarshi 'Rishi' Ray wrote:
> Contact https://fedoraproject.org/wiki/ThomasCanniot
I had CC'ed him in the previous mail. :-)
I only see Jeremy on the CC list.
Rahul
11:35 a.m.
I only see Jeremy on the CC list.
Here is a portion of the mail's header. :-)
Message-ID: <3170f42f0707030904w2b194fbcm43a13f48e02c403(a)mail.gmail.com>
Date: Tue, 3 Jul 2007 21:34:33 +0530
From: "Debarshi 'Rishi' Ray" <debarshi.ray(a)gmail.com>
Reply-To: debarshi.ray(a)gmail.com
To: "Development discussions related to Fedora Core"
<fedora-devel-list(a)redhat.com>
Subject: Re: Pirut: Edit -> Repositories
Cc: "Jeremy Katz" <katzj(a)redhat.com>,
"Sankarshan Mukhopadhyay" <sankarshan.mukhopadhyay(a)gmail.com>,
splinux(a)fedoraproject.org, mrtom(a)fedoraproject.org
Regards,
Debarshi
--
GPG key ID: 63D4A5A7
Key server: pgp.mit.edu
4:54 p.m.
>> I only see Jeremy on the CC list.
> Here is a portion of the mail's header. :-)
Strange. Thunderbird only shows one CC.
Might be a bug. :-)
Cheers,
Debarshi
--
GPG key ID: 63D4A5A7
Key server: pgp.mit.edu
5:30 p.m.
Le mardi 03 juillet 2007, Rahul Sundaram a écrit :
Debarshi 'Rishi' Ray wrote:
>> Contact https://fedoraproject.org/wiki/ThomasCanniot
>
> I had CC'ed him in the previous mail. :-)
I only see Jeremy on the CC list.
I confirm, using kmail.
Regards
Alain
--
Les pages de manuel Linux en français
http://manpagesfr.free.fr/
11:41 a.m.
> I only see Jeremy on the CC list.
I confirm, using kmail.
Hence GMail's Web interface rocks. :-)
Cheers,
Debarshi
--
GPG key ID: 63D4A5A7
Key server: pgp.mit.edu
11:52 a.m.
Debarshi 'Rishi' Ray wrote:
> > I only see Jeremy on the CC list.
> I confirm, using kmail.
Hence GMail's Web interface rocks. :-)
I can't see how a CC list that is invisible to everybody else (assumed
that is actually working) is going to be better than a CC list that is
transparent to desktop clients.
Rahul
11:57 a.m.
I can't see how a CC list that is invisible to everybody else
(assumed
that is actually working) is going to be better than a CC list that is
transparent to desktop clients.
I gave you the original mail headers. As long as the mail reaches its
destination I do not care. :-/
Regards,
Debarshi
--
GPG key ID: 63D4A5A7
Key server: pgp.mit.edu
12:02 p.m.
Debarshi 'Rishi' Ray wrote:
> I can't see how a CC list that is invisible to everybody else
(assumed
> that is actually working) is going to be better than a CC list that is
> transparent to desktop clients.
I gave you the original mail headers. As long as the mail reaches its
destination I do not care. :-/
If the web interface is mangling the headers in a way that makes it
invisible to other clients then it is a bug and not a benefit.
Rahul
11:57 a.m.
Debarshi 'Rishi' Ray wrote:
>> I only see Jeremy on the CC list.
> I confirm, using kmail.
Hence GMail's Web interface rocks. :-)
No, it mustn't. If it rocked, it would have properly included the
CC's. If you see them in gmail, then it's showing you things that are
not there. :)
--
Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Between two evils, I always pick the one I never tried before.
-- Mae West
12:17 p.m.
No, it mustn't. If it rocked, it would have properly included
the
CC's. If you see them in gmail, then it's showing you things that are
not there. :)
From what I can see, and I can only see the mail header at my end, it
did include the CCs. I already gave you the mail headers. :-)
Moreover it seems from Thomas Canniot's <mrtom(a)fedoraproject.org>
reply, which he sent to me privately that he actually got the mail.
I am not an expert in email protocols, but I suspect that the CC worked.
In case you want to investigate I can send you all the headers offlist. :-)
Cheers,
Debarshi
--
GPG key ID: 63D4A5A7
Key server: pgp.mit.edu
11:58 p.m.
Debarshi 'Rishi' Ray wrote:
https://fedoraproject.org/wiki/Usability/Objectives/Pirut
There are some designs already available on the above link. Can I have
a look at the source code used to create them?
Thanks,
Debarshi
All the code for selecting repositories to use you can find in yumex.
http://svn.sourceforge.net/viewvc/yumex/trunk/yumex/src/
Tim
11:51 p.m.
Rahul Sundaram wrote:
Tim Lauridsen wrote:
>>
> Sounds like a good idea, the config write routine in yum will remove
> all the # comment lines and mix all the options.
> I fixed the mixing in system-config-repo by building a extra layer on
> the yum config API, but it don't take care off the # comments.
> I would be a good idea to teach yum to save config files, without
> losing information.
This might be a good time to rethink whether Pirut and YumEx should be
merged together. Recent YumEx changes have made it look more and more
like Pirut and Pirut is started to grow more features similar to
YumEx. Looks like they are converging to me. Any reasons not to merge?
Rahul
I purposed it a couple of times to Jeremy, most of the things pirut and
yumex does, is the same, installing package groups and find and
install/remove selected packages. there are both build on the top of the
yum api, but there is some differences.
pirut tries to be more simple, with the same look as the package
selection as in anaconda.
Yumex add more advanced features like selecting what repositories to use
and also it is more verbose (I like to see what is going on ) and i have
tried to made it as responsive as possible. (I have done some ugly
threaded stuff to update gui).
A merge would be fine to me, but it is mostly about where we want to go
with the package manager in Fedora, do we want a simple tools or do we
want tools with lot of possibilities for the more advanced user.
Tim
4:11 a.m.
Tim Lauridsen wrote:
>
I purposed it a couple of times to Jeremy, most of the things pirut and
yumex does, is the same, installing package groups and find and
install/remove selected packages. there are both build on the top of the
yum api, but there is some differences.
pirut tries to be more simple, with the same look as the package
selection as in anaconda.
Yumex add more advanced features like selecting what repositories to use
and also it is more verbose (I like to see what is going on ) and i have
tried to made it as responsive as possible. (I have done some ugly
threaded stuff to update gui).
A merge would be fine to me, but it is mostly about where we want to go
with the package manager in Fedora, do we want a simple tools or do we
want tools with lot of possibilities for the more advanced user.
Well I understand the original arguments against it which I have been
supportive of but it looks like the tools are converging. Whatever
advanced features are in Yumex end up being requested against Pirut.
I would say there is more value in merging together now.
Rahul
5:45 a.m.
Well I understand the original arguments against it which I have
been
supportive of but it looks like the tools are converging. Whatever
advanced features are in Yumex end up being requested against Pirut.
By "it" you refer to Yumex? What were the arguments?
Regards,
Debarshi
--
GPG key ID: 63D4A5A7
Key server: pgp.mit.edu
6:17 a.m.
Debarshi 'Rishi' Ray wrote:
> Well I understand the original arguments against it which I have
been
> supportive of but it looks like the tools are converging. Whatever
> advanced features are in Yumex end up being requested against Pirut.
By "it" you refer to Yumex? What were the arguments?
I am referring to merging yumex and pirut. The arguments against that
was already described by Tim Lauridsen.
Rahul
4:28 a.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Tim Lauridsen wrote:
A merge would be fine to me, but it is mostly about where we want to
go
with the package manager in Fedora, do we want a simple tools or do we
want tools with lot of possibilities for the more advanced user.
Simplicity is a desirable goal and rightly one should strive for it, the
question remains would a merged tool ie an extended/improved/feature
rich Pirut or a Yumex with possible extensions serve the ends ? And of
course, would at the end the choice will boil down to a single tool ?
:Sankarshan
- --
You see things; and you say 'Why?';
But I dream things that never were;
and I say 'Why not?' - George Bernard Shaw
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iD8DBQFGi2hWXQZpNTcrCzMRAkA/AJsEO9NNzMc6t/a9amletwzdJL2w8QCgsjkG
ZlaSONjHY+psIucye+FOB14=
=1vsx
-----END PGP SIGNATURE-----
7:32 a.m.
On 7/4/07, Sankarshan Mukhopadhyay <sankarshan.mukhopadhyay(a)gmail.com>
> A merge would be fine to me, but it is mostly about where we
want to go
> with the package manager in Fedora, do we want a simple tools or do we
> want tools with lot of possibilities for the more advanced user.
Simplicity is a desirable goal and rightly one should strive for it, the
question remains would a merged tool ie an extended/improved/feature
rich Pirut or a Yumex with possible extensions serve the ends ? And of
course, would at the end the choice will boil down to a single tool ?
+1 to a single tool for managing repos globally, rather than every
apps have its own repo control, which is , IMHO, make stuff feels more
complicated ..
I like system-config-repo's and repoman's approach .. pirut just
install/remove apps.. repoman/sysconfrepo for all-thing repository
related .. and yumex for advanced users ..
a textUI (eg: system-config-repo-tui) for enabling/disabling repos is
also a nice thing to have .. it make it easier for writing automated
scripts etc. (I had this problem before , enabling/disabling repos
globally was a pain for a person who dont know much in manipulating
strings in scripts like me - or maybe such app already exist but I
dont know about it???)
--
-----------------------------------------------
regards
Hikaru
-----------------------------------------------
Mohd Izhar Firdaus Bin Ismail
Amano Hikaru
天野晃 「あまの ひかる」
mohd.izhar.firdaus(a)gmail.com
-----------------------------------------------
kagesenshi.87(a)gmail.com
Blog: http://kagesenshi.blogspot.com
http://fedoraproject.org/wiki/MohdIzharFirdaus
-----------------------------------------------
8:53 a.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hikaru Amano wrote:
+1 to a single tool for managing repos globally, rather than every
apps have its own repo control, which is , IMHO, make stuff feels more
complicated ..
Umm...ok let me rephrase the query. Is this a move towards a single tool
or is this a move towards a single way of handling repository
information with multiple tools being able to access it and perhaps
provide enhanced functionality. The second method does mean that the
metadata required to be handle would perhaps require discussion
- --
You see things; and you say 'Why?';
But I dream things that never were;
and I say 'Why not?' - George Bernard Shaw
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iD8DBQFGi6ZhXQZpNTcrCzMRAqV/AJ9S9GGvrnX8GYy/Ka1N+mcGCdZwwgCcDRGd
bEYfYoTGXE33qXiKK67lqGo=
=2hBT
-----END PGP SIGNATURE-----
11:39 a.m.
Just a moment. I am getting lost on this.
+1 to a single tool for managing repos globally, rather than every
apps have its own repo control, which is , IMHO, make stuff feels more
complicated ..
The YUM API already has a way to enable and disable repositories. The
--enablerepo and --disablerepo flags directly use this.
What seems to be lacking is a way to alter yum.conf and the .repo
files so that the changes become persistent. Once this is available in
the YUM API, all that an application needs to do is make calls to this
API component to do the necessary configuration.
So right now applications need to have their own repository control
only if they want to alter the files, not if they want to enable or
disable a repository for a single run of the program.
What you refer to as "a single tool for managing repos globally" is
actually the YUM API. Using that there can be 'n' number of frontends
(GUI or CLI) which can configure repositories among other things too.
I like system-config-repo's and repoman's approach .. pirut
just
install/remove apps.. repoman/sysconfrepo for all-thing repository
related .. and yumex for advanced users ..
Why would one need a separate tool for doing each of these things? As
far as I understand, one would only need to work with repositories if
they want to install/update/remove some packages. Hence a tool which
claims to be a package manager (GUI or CLI) should have all the
features. eg., if A, B, and C claim to be package management tools,
then each of them should have these features to some extent atleast.
a textUI (eg: system-config-repo-tui) for enabling/disabling repos
is
also a nice thing to have .. it make it easier for writing automated
scripts etc. (I had this problem before , enabling/disabling repos
globally was a pain for a person who dont know much in manipulating
strings in scripts like me - or maybe such app already exist but I
dont know about it???)
Again I can not visualize repository configuration as a separate thing
from package management.
Happy hacking,
Debarshi
--
GPG key ID: 63D4A5A7
Key server: pgp.mit.edu
12:02 p.m.
On 7/5/07, Debarshi 'Rishi' Ray <debarshi.ray(a)gmail.com> wrote:
Just a moment. I am getting lost on this.
> +1 to a single tool for managing repos globally, rather than every
> apps have its own repo control, which is , IMHO, make stuff feels more
> complicated ..
The YUM API already has a way to enable and disable repositories. The
--enablerepo and --disablerepo flags directly use this.
What seems to be lacking is a way to alter yum.conf and the .repo
files so that the changes become persistent. Once this is available in
the YUM API, all that an application needs to do is make calls to this
API component to do the necessary configuration.
yup .. I'm looking for a way to alter yum.conf and the .repo file to
become persistent .. I have set up a LAN repo for newbies in my uni
and was trying to make a one click installation script for it ... I
dont want to tell them to manually edit all the .repo files one by one
to disable the official repos and enable my repos...
--
-----------------------------------------------
regards
Hikaru
-----------------------------------------------
Mohd Izhar Firdaus Bin Ismail
Amano Hikaru
天野晃 「あまの ひかる」
mohd.izhar.firdaus(a)gmail.com
-----------------------------------------------
kagesenshi.87(a)gmail.com
Blog: http://kagesenshi.blogspot.com
http://fedoraproject.org/wiki/MohdIzharFirdaus
-----------------------------------------------
12:07 p.m.
Hikaru Amano wrote:
On 7/5/07, Debarshi 'Rishi' Ray
<debarshi.ray(a)gmail.com> wrote:
> Just a moment. I am getting lost on this.
>
> > +1 to a single tool for managing repos globally, rather than every
> > apps have its own repo control, which is , IMHO, make stuff feels more
> > complicated ..
>
> The YUM API already has a way to enable and disable repositories. The
> --enablerepo and --disablerepo flags directly use this.
>
> What seems to be lacking is a way to alter yum.conf and the .repo
> files so that the changes become persistent. Once this is available in
> the YUM API, all that an application needs to do is make calls to this
> API component to do the necessary configuration.
>
yup .. I'm looking for a way to alter yum.conf and the .repo file to
become persistent .. I have set up a LAN repo for newbies in my uni
and was trying to make a one click installation script for it ... I
dont want to tell them to manually edit all the .repo files one by one
to disable the official repos and enable my repos...
Rum (The original one, not Debarshi's) did have easy command line
arguments for disabling/enabling repositories in a persistent manner.
They probably have custom code to do this but you might want to take a
look at that.
Rahul
3:20 p.m.
Rum (The original one, not Debarshi's) did have easy command
line
arguments for disabling/enabling repositories in a persistent manner.
They probably have custom code to do this but you might want to take a
look at that.
Thanks for the pointer. The RUM (original one) code looks much more
cleaner to me than Yumex's and is smaller in size too.
Let me see if I can integrate this into the YUM API.
Happy hacking,
Debarshi
--
GPG key ID: 63D4A5A7
Key server: pgp.mit.edu
11:51 a.m.
On Thu, 2007-07-05 at 01:02 +0800, Hikaru Amano wrote:
On 7/5/07, Debarshi 'Rishi' Ray
<debarshi.ray(a)gmail.com> wrote:
> Just a moment. I am getting lost on this.
>
> > +1 to a single tool for managing repos globally, rather than every
> > apps have its own repo control, which is , IMHO, make stuff feels more
> > complicated ..
>
> The YUM API already has a way to enable and disable repositories. The
> --enablerepo and --disablerepo flags directly use this.
>
> What seems to be lacking is a way to alter yum.conf and the .repo
> files so that the changes become persistent. Once this is available in
> the YUM API, all that an application needs to do is make calls to this
> API component to do the necessary configuration.
>
yup .. I'm looking for a way to alter yum.conf and the .repo file to
become persistent .. I have set up a LAN repo for newbies in my uni
and was trying to make a one click installation script for it ... I
dont want to tell them to manually edit all the .repo files one by one
to disable the official repos and enable my repos...
FWIW, the best way to actually do this now is to set yourself up as a
private mirror in mirror manager
(https://admin.fedoraproject.org/mirrormanager) with an IP range set.
Then, clients connecting and asking for the mirror list from your IP
range will get back the local mirror. Then the users don't have to do
anything and it Just Works (tm)
Jeremy
1:52 p.m.
On 7/6/07, Jeremy Katz <katzj(a)redhat.com> wrote:
> yup .. I'm looking for a way to alter yum.conf and the .repo
file to
> become persistent .. I have set up a LAN repo for newbies in my uni
> and was trying to make a one click installation script for it ... I
> dont want to tell them to manually edit all the .repo files one by one
> to disable the official repos and enable my repos...
FWIW, the best way to actually do this now is to set yourself up as a
private mirror in mirror manager
(https://admin.fedoraproject.org/mirrormanager) with an IP range set.
Then, clients connecting and asking for the mirror list from your IP
range will get back the local mirror. Then the users don't have to do
anything and it Just Works (tm)
Jeremy
I know about mirrormanager .. but no matter how much I would love to
use it , I couldnt .. :(
the network in my college is set up like a very paranoid network ..
where theres 6 separated networks that couldnt connect to each other ,
and 1 central network that become the center of all 7 networks. theres
a proxy farm in the central network that allows connection between the
6 networks , however, it have a crazy limitation. port 80 POST/GET
with 2MB size limit and port 443 TCP/CONNECT .. and no other protocols
allowed .. this limitation also applies to normal internet
connection.. I managed to get around that and mirrored Fedora's
repository locally for others who dont know how to sneak through the
network.
considering yum doesnt support https, I had to write a set of
automated scripts complete with init to start a tunneling application
(prtunnel), and create a CONNECT tunnel to my http server running on
port 443 through the proxy. I even wrote a simple yum plugin to make
sure the tunnel is running before yum'ing. all of that are packaged
into a rpm which will handle all the dirty work for them. The only
problem I have now is a way to easily switch between using Fedora's
official repository or my mirrored+tunneled repository on localhost.
My current approach of enabling/disabling repos is very ugly where i
renames the .repo files accordingly ..
I know my case is >= 0.1% of the entire population of Fedora users, so
I try not to demand big stuff like https + https_proxy support in yum
(which will solves not only this problem .. but some of my other small
problems too), rather than some little help in getting something to
work.. Everything else , I will manage to do it .... somehow ......
--
-----------------------------------------------
regards
Hikaru
-----------------------------------------------
Mohd Izhar Firdaus Bin Ismail
Amano Hikaru
天野晃 「あまの ひかる」
mohd.izhar.firdaus(a)gmail.com
-----------------------------------------------
kagesenshi.87(a)gmail.com
Blog: http://kagesenshi.blogspot.com
http://fedoraproject.org/wiki/MohdIzharFirdaus
-----------------------------------------------
6:40 p.m.
On 7/6/07, seth vidal <skvidal(a)linux.duke.edu> wrote:
On Fri, 2007-07-06 at 02:52 +0800, Hikaru Amano wrote:
> considering yum doesnt support https, I had to write a set of
yes, yum supports https just fine.
is it? ... since when?. .. the last time I tried (around FC5/early
FC6) ... iirc, that time, https doesnt work .. (or was it .. https
doesnt work through https_proxy?? .. ) .. I tried several times and
still couldnt connect to the server .. thus .. lead me to derive the
auto tunneling scripts etc to get around it ..
-sv
--
fedora-devel-list mailing list
fedora-devel-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
--
-----------------------------------------------
regards
Hikaru
-----------------------------------------------
Mohd Izhar Firdaus Bin Ismail
Amano Hikaru
天野晃 「あまの ひかる」
mohd.izhar.firdaus(a)gmail.com
-----------------------------------------------
kagesenshi.87(a)gmail.com
Blog: http://kagesenshi.blogspot.com
http://fedoraproject.org/wiki/MohdIzharFirdaus
-----------------------------------------------
9:29 p.m.
On Fri, 2007-07-06 at 07:40 +0800, Hikaru Amano wrote:
On 7/6/07, seth vidal <skvidal(a)linux.duke.edu> wrote:
> On Fri, 2007-07-06 at 02:52 +0800, Hikaru Amano wrote:
>
> > considering yum doesnt support https, I had to write a set of
>
>
> yes, yum supports https just fine.
is it? ... since when?. .. the last time I tried (around FC5/early
FC6) ... iirc, that time, https doesnt work .. (or was it .. https
doesnt work through https_proxy?? .. ) .. I tried several times and
still couldnt connect to the server .. thus .. lead me to derive the
auto tunneling scripts etc to get around it ..
https definitely works and the last time I checked the proxy worked,
too. If you've got a bug, file it and let's take a look, okay b/c it
_should_ work.
-sv
2:05 p.m.
the network in my college is set up like a very paranoid network ..
where theres 6 separated networks that couldnt connect to each other ,
and 1 central network that become the center of all 7 networks. theres
a proxy farm in the central network that allows connection between the
6 networks , however, it have a crazy limitation. port 80 POST/GET
with 2MB size limit and port 443 TCP/CONNECT .. and no other protocols
allowed .. this limitation also applies to normal internet
connection.. I managed to get around that and mirrored Fedora's
repository locally for others who dont know how to sneak through the
network.
I had a very similar set-up in my university too. We did not have the
2MB size limit though. :-)
Cheers,
Debarshi
--
GPG key ID: 63D4A5A7
Key server: pgp.mit.edu
11:49 a.m.
> A merge would be fine to me, but it is mostly about where we want
to go
> with the package manager in Fedora, do we want a simple tools or do we
> want tools with lot of possibilities for the more advanced user.
Simplicity is a desirable goal and rightly one should strive for it,
the
question remains would a merged tool ie an extended/improved/feature
rich Pirut or a Yumex with possible extensions serve the ends ? And of
course, would at the end the choice will boil down to a single tool ?
In certain cases the idea of a simple packagement tool can lead to
oversimplification of things.
For example for a very long time in the days of FC2 to FC5 Pirut would
not work on LANs which connected to the Internet through a proxy. It
would simply exit with a message: "Can not download package
information". I have seen many many users who would really appreciate
a simple tool getting stumped by this and dump Pirut for good.
In such cases an option to set the proxy would have been wonderful.
These very same users would happily use Synaptic after providing the
necessary proxy settings for their network.
My point is that a configuration option which lies within the menu
does not really lead to loss of any simplicity. Rather it may enhance
the usability of the entire application at times.
Secondly, do we really a simple package manager and an advanced
package manager? In my opinion this would be an overkill.
Regards,
Debarshi
--
GPG key ID: 63D4A5A7
Key server: pgp.mit.edu
11:58 a.m.
Debarshi 'Rishi' Ray wrote:
>> A merge would be fine to me, but it is mostly about where we
want to go
>> with the package manager in Fedora, do we want a simple tools or do we
>> want tools with lot of possibilities for the more advanced user.
> Simplicity is a desirable goal and rightly one should strive for it, the
> question remains would a merged tool ie an extended/improved/feature
> rich Pirut or a Yumex with possible extensions serve the ends ? And of
> course, would at the end the choice will boil down to a single tool ?
In certain cases the idea of a simple packagement tool can lead to
oversimplification of things.
For example for a very long time in the days of FC2 to FC5 Pirut would
not work on LANs which connected to the Internet through a proxy.
That doesn't make much sense. Pirut is a new tool introduced in FC5.
system-config-packages which existed in previous versions didn't use
yum, only had the capability to install packages from media and would
have no need to connect to the Internet or use a proxy. Proxy settings
would ideally be system wide and not require per application configuration.
Rahul
4:37 a.m.
I think the place to start is with writing up some use cases and
then
trying to do some mockups from there before ever writing any code.
I have a preliminary design. When it is ready I shall put it up and
let you know. Would love to have your comments then. :-)
Then the tricky part is likely to be doing the config reading/writing
in
a way that's not lossy. repoman actually has a good start on some of
this, but it'd be nice to actually work towards getting that code into
yum itself so that every tool doesn't have to re-invent those bits.
For the time being we can atleast have a GUI interface that does what
'yum --enablerepo' and 'yum --disablerepo' does, and then incorporate
the .repo file handling part gradually.
What do you think?
Happy hacking,
Debarshi
--
GPG key ID: 63D4A5A7
Key server: pgp.mit.edu
6144
days inactive
6148
days old
43 comments
9 participants
participants (9)
-
Alain PORTAL -
Debarshi Ray -
Jeremy Katz -
Mohd Izhar Firdaus Ismail -
Rahul Sundaram -
Sankarshan Mukhopadhyay -
seth vidal -
Tim Lauridsen -
Todd Zullinger