[Yum] future stuff, again

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



--=-xlT7ZMskAfHwrIQrF3LT
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Tue, 2002-08-27 at 15:40, Connie Sieh wrote:
> One reason why I selected yum was because it was small and easy and did
> not have lots of options which only confuse the users.
>=20
> 	I need a way to update out of date rpms automatically.
>=20
> 	I need a easier way(than downloading via ftp after figuring out
> 	lots of dependencies) for end users to install new rpms.
>=20
> 	I need a way for end users to update out of date rpms.
>=20
> Sure there are other things that would be nice.  One of those was the
> mirroring.  So yum did not do it so Troy wrote scripts to do it for us.
>=20

so I'm going to respond to rob's comments and your's here:

I agree about a simple interface for a user. I don't want to add
complexity if it doesn't help me out. I liked yup, from a while back,
and I thought the interface was REALLY easy - I just told it what I
wanted and it got it - but it wasn't fast and it broke a lot, so yum is
fairly fast in comparison and it is less prone to breaking, I think.

but its got to continue doing what I want - which is update a bunch of
systems easily and allow me to install stuff whenever I want it w/o
having to hunt for things.

However, I think we can add options w/o adding more work - ie - make the
advanced features be just that -advanced - but not required.

so I'd like to think someone could continue telling users:

yum update
yum install [blah blah blah]
yum remove [blah blah blah]

that I'm cool with and I think that should probably be the default set
of arguments

but I  think rob might have a point - some of those features could be
useful - but I think they should be renamed/organized.

most of that will involve trying things and seeing what sucks and what
doesn't suck and how to keep from breaking people's scripts too badly.
Thats why I wanted to have this discussion to see what things should be
included so I know what to be worried about.


> The question if install should update is a good one.  I cannot think of a
> reason to not update as the default way of doing it but there may be a
> case.  One could always install then do a update but then we would have t=
o
> train the users again.  So maybe a switch that only installs but have the
> default install option to update if necessary.

I think as troy put it was good.

yum update - update only - if its not update-able then error out.
yum install - update if its installed already, otherwise just install -
however, if its installed and current then bail with a "this is
installed, you dolt." error.=20

no retraining necessary.


To rob's requests:
 yum ain't going to parse kickstarts.cfg anytime soon, quit dreaming.:)

however, I like the idea of a url-retrievable command file.

ideally so one could have a "script" of commands that a single yum
session would run through. It could speed up multiple-operations
tremendously, but there is thinking to be done here, before thats
implemented.

 Regarding dist-version upgrades - I think that can happen - but there
might be a couple hangups to making it happen smoothly - right now yum
scratches an itch - if its going to have more infrastructure to include
things like dist-commands i'd like to sit down and plan out those steps.


Connie/Troy:
 regarding mirroring - tell me again the situation you're in and how you
want to deal with it, then I can see if I can actually implement
mirroring in yum where it will be helpful to you/others.



Just in general, right now, yum, excluding package groups, does what I
wanted it to do - I'm fairly pleased with how some of it has turned out
and I'd like to thank all of y'all on this list for your
help/suggestions/patches/code etc


-sv



--=-xlT7ZMskAfHwrIQrF3LT
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQA9bFAR1Aj3x2mIbMcRAuPFAKCfIrBTKOMw9Bd6UgwRQP3Dp8J8AgCePvuW
EqnTgtQ9I7x4KkwSDokbIDw=
=KtrM
-----END PGP SIGNATURE-----

--=-xlT7ZMskAfHwrIQrF3LT--



[Index of Archives]     [Fedora Users]     [Fedora Legacy List]     [Fedora Maintainers]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]

  Powered by Linux