SCIENTIFIC-LINUX-DEVEL Archives

December 2010

SCIENTIFIC-LINUX-DEVEL@LISTSERV.FNAL.GOV

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Troy Dawson <[log in to unmask]>
Reply To:
Troy Dawson <[log in to unmask]>
Date:
Mon, 6 Dec 2010 08:55:54 -0600
Content-Type:
text/plain
Parts/Attachments:
text/plain (52 lines)
Herb Thompson wrote:
> I've installed SL6 Alpha 1 as a VirtualBox (Version 3.2.12) guest on an 
> XP SP3 host.  It seems to run well with 512 MB of guest memory; and 
> basic guest-additions features like shared folders and full-screen mode 
> seem to work.
> 
> Don't know if this is useful feedback at the alpha stage, but for 
> whatever its worth: the dkms and yum-conf-epel packages don't seem to be 
> in the repo.
dkms
- For SL6, we have been asked by the scientific community, to not 
duplicate packages found in the main external repositories (epel, 
rpmforge, ... ), unless there is a valid reason.
Both dkms and ndiswrapper have come up as packages that a person might 
need to get on the network in order to access the repositories.
But if we are to add drivers to the distribution so that people can 
access these repositories, I would like them to be in the format that 
elrepo has them in.
So I would like to not add dkms, unless there really isn't a better way 
to get network drivers installed.

yum-conf-epel
- It should be there in the beta, or actually epel-release should.
Which brings up a question.
In the past, we have made the yum repository packages "yum-conf-blah" 
with blah being the name of the repository, such as yum-conf-epel.
In my mind, that is the correct way to do things, and it makes sense to me.
But the rest of the world doesn't seem to do that.  Everyone else put's 
their yum repostories in blah-release, such as epel-release or 
elrepo-release.
So, for SL6 is was planning on taking the blah-release from the various 
compatible repositories (epel, rpmforge, atrpms, elrepo) and putting 
them into the release, without any changes if possible.
I see both pro's and con's with this.

Pro
- less work
- it will be the same if they install the repo from us, or get it from 
the repo directly

Con
- longtime SL users will expect yum-conf-blah
- I'm not sure that all the repositories have priorities set in their 
default repo setups.

Troy
-- 
__________________________________________________
Troy Dawson  [log in to unmask]  (630)840-6468
Fermilab  ComputingDivision/SCF/FEF/SLSMS Group
__________________________________________________

ATOM RSS1 RSS2