Menu
▾
▴
linuxcoe-devel
|
From: Bryan G. <bry...@hp...> - 2009-02-22 15:51:40
|
FYI,
For some time, I have been watching some of our users struggle with
how to name their OSVEND entries (and thus all of the config file
snippets). Bottom line it comes down to a matter of consistency, but
since our code currently does some specific checks (eg. Fedora), they
are really stuck with our naming conventions.
I recently did some looking around at the various distros and was kinda
surprised/disappointed as to the lack of consistency there as well:
CentOS
(pretty consistent except for directory structures centos)
Debian
(refers to itself in text this way, yet all logos and d/loads are "debian")
Fedora
(same camp as Debian/debian)
openSUSE
(over time they have migrated to this capitalization, and are now
surprisingly consistent)
RedHat
(chuckle, on their home page alone there are instances of REDHAT, RedHat, redhat with and without spacing)
Scientific
(seems fairly consistent as Scientific Linux or SL)
SuSE
(seems Novell has migrated to SUSE, save for the directory structure suse,
and all of their current offerings are SLE*)
Ubuntu
(same camp as Debian/debian)
VMWare
(mostly go by VMware)
So, I was wondering about this possibility. In the code, should we perhaps
do all our checks as "DISTRO" or maybe "distro" and then frontend all of
our parsing with the respective toupper or tolower functions to be as
liberal with inputs, and strict with outputs?
bryang
|
|
From: Bruno C. <Bru...@hp...> - 2009-02-22 15:59:13
|
Hello Bryan, Just wanted to add Mandriva/Mandrake which is a mess in itself :-( Bryan Gartner said on Sun, Feb 22, 2009 at 08:33:49AM -0700: > So, I was wondering about this possibility. In the code, should we perhaps > do all our checks as "DISTRO" or maybe "distro" and then frontend all of > our parsing with the respective toupper or tolower functions to be as > liberal with inputs, and strict with outputs? Applause !!! THat would help me a lot in what I'm trying to do outside of LinuxCOE and hopefully inside soon. As an old-time Unix user, I'm inclined towards lc myself, but I don't care as long as we can standardize on a single one and use it everywhere ! We could even consider using that distro-release file under /etc to get more info (except for Ubuntu which decided to not create one :-() Excellent initiative. Just hope it doesn't create too much problem at the code level. Bruno. -- Linux Profession Lead EMEA / Open Source Ambassador \ EMEA CME SoL. Center http://www.mondorescue.org / HP/Intel Solution Center \ http://hpintelco.net Des infos sur Linux? http://www.HyPer-Linux.org http://www.hp.com/linux La musique ancienne? http://www.musique-ancienne.org http://www.medieval.org |
|
From: Bryan G. <bry...@hp...> - 2009-02-22 17:16:59
|
Bruno, > Just wanted to add Mandriva/Mandrake which is a mess in itself :-( Oops, yes, a total oversight, sorry. We'll probably rely/expand some on our "distmap" table. > > So, I was wondering about this possibility. In the code, should we perhaps > > do all our checks as "DISTRO" or maybe "distro" and then frontend all of > > our parsing with the respective toupper or tolower functions to be as > > liberal with inputs, and strict with outputs? > > Applause !!! THat would help me a lot in what I'm trying to do outside > of LinuxCOE and hopefully inside soon. > > As an old-time Unix user, I'm inclined towards lc myself, but I don't > care as long as we can standardize on a single one and use it everywhere > ! We could even consider using that distro-release file under /etc to > get more info (except for Ubuntu which decided to not create one :-() As noted, I'm suggesting we accept all case(s) as input, and just use one standard internally (which actually becomes immaterial to most all users then. So: Fedora fedora fEDORA ... (even if not consistent across all inputs) would all be acceptable as configuration values. > Excellent initiative. Just hope it doesn't create too much problem at > the code level. Easy to suggest it, now will have to access/implement it, bryang |
|
From: Lee M. <lee...@hp...> - 2009-02-23 12:36:08
|
Gartner, Bryan W wrote: > Bruno, > > >> Just wanted to add Mandriva/Mandrake which is a mess in itself :-( >> > > Oops, yes, a total oversight, sorry. We'll probably rely/expand some > on our "distmap" table. > > >>> So, I was wondering about this possibility. In the code, should we perhaps >>> do all our checks as "DISTRO" or maybe "distro" and then frontend all of >>> our parsing with the respective toupper or tolower functions to be as >>> liberal with inputs, and strict with outputs? >>> >> Applause !!! THat would help me a lot in what I'm trying to do outside >> of LinuxCOE and hopefully inside soon. >> >> As an old-time Unix user, I'm inclined towards lc myself, but I don't >> care as long as we can standardize on a single one and use it everywhere >> ! We could even consider using that distro-release file under /etc to >> get more info (except for Ubuntu which decided to not create one :-() >> > > As noted, I'm suggesting we accept all case(s) as input, and just > use one standard internally (which actually becomes immaterial to > most all users then. So: > > Fedora > fedora > fEDORA > ... > (even if not consistent across all inputs) > > would all be acceptable as configuration values. > > >> Excellent initiative. Just hope it doesn't create too much problem at >> the code level. >> > > Easy to suggest it, now will have to access/implement it, > > bryang > > This is an excellent suggestion and I'd been thinking about it a little since Bruno originally suggested it last year. I'd run into a bit of a 'brain freeze' on the issue, but thinking a little more and Bruno's lc() nudge I think it will be easier to implement than I had originally thought. I'll see if I can get a proof of concept working real soon. Bryan, now might be a good time for a 'snapshot' release as I expect there will be many moving parts soon. :^) Best Regards, Lee |
|
From: Bruno C. <Bru...@hp...> - 2009-02-23 13:07:20
|
Lee Mayes said on Mon, Feb 23, 2009 at 06:39:26AM -0500: > Bryan, now might be a good time for a 'snapshot' release as I expect there > will be many moving parts soon. :^) If you plan on an upcoming release, I'd be happy to provide packages that you could test. Bruno. -- Linux Profession Lead EMEA / Open Source Ambassador \ EMEA CME SoL. Center http://www.mondorescue.org / HP/Intel Solution Center \ http://hpintelco.net Des infos sur Linux? http://www.HyPer-Linux.org http://www.hp.com/linux La musique ancienne? http://www.musique-ancienne.org http://www.medieval.org |
|
From: Bryan G. <bry...@hp...> - 2009-02-23 15:53:09
|
FYI,
On Mon, Feb 23, 2009 at 11:39:26AM +0000, Mayes, Lee wrote:
> Gartner, Bryan W wrote:
> >>> So, I was wondering about this possibility. In the code, should we perhaps
> >>> do all our checks as "DISTRO" or maybe "distro" and then frontend all of
> >>> our parsing with the respective toupper or tolower functions to be as
> >>> liberal with inputs, and strict with outputs?
> >>>
> >> Applause !!! THat would help me a lot in what I'm trying to do outside
> >> of LinuxCOE and hopefully inside soon.
> >>
> >> As an old-time Unix user, I'm inclined towards lc myself, but I don't
> >> care as long as we can standardize on a single one and use it everywhere
> >> ! We could even consider using that distro-release file under /etc to
> >> get more info (except for Ubuntu which decided to not create one :-()
My current plan is to create all of our items using lsb_release -a output
as the standard. Within the code, Lee can make the determination regarding
upper/lower/mixed case for the checks and for the mapping.
> > As noted, I'm suggesting we accept all case(s) as input, and just
> > use one standard internally (which actually becomes immaterial to
> > most all users then. So:
> >
> > Fedora
> > fedora
> > fEDORA
> > ...
> > (even if not consistent across all inputs)
> >
> > would all be acceptable as configuration values.
> >
> >
> >> Excellent initiative. Just hope it doesn't create too much problem at
> >> the code level.
> >>
> >
> > Easy to suggest it, now will have to access/implement it,
> >
> > bryang
> >
> >
> This is an excellent suggestion and I'd been thinking about it a little
> since Bruno originally suggested it last year. I'd run into a bit of a
> 'brain freeze' on the issue, but thinking a little more and Bruno's lc()
> nudge I think it will be easier to implement than I had originally
> thought. I'll see if I can get a proof of concept working real soon.
>
> Bryan, now might be a good time for a 'snapshot' release as I expect
> there will be many moving parts soon. :^)
Ok, here is my plan du'jour.
Since we already did a 4.1 "release" (almost one year ago) and
a set of packages, I'll rev the current HEAD to tag v4_2 and do
another set of tar.gz/packages (using Bruno's project-builder),
then move HEAD to start generating 4.3 for all the upcoming
snapshots/work.
This will probably take me a few days to walk through and get setup
as I try to integrate project-builder into the process. I'll reply
back here when the above is completed.
bryang
|
|
From: Bruno C. <Bru...@hp...> - 2009-02-23 16:44:52
|
Bryan Gartner said on Mon, Feb 23, 2009 at 08:52:09AM -0700: > My current plan is to create all of our items using lsb_release -a output > as the standard. Interesting. On my Mandriva distro it gives: LSB Version: lsb-3.1-amd64:lsb-3.1-noarch:* Distributor ID: MandrivaLinux Description: Mandriva Linux 2009.0 Release: 2009.0 Codename: zarapha However, the lsb package is optional on most distro. And then, it uses .etc.distro-release, except on Debian where it doesn't exist ;-) Interesting to see that I arrived at a similar solution, but not requiring the lsb package to be present in my pbdistrocheck package. I'll submit it to CPAN now that I have an account BTW. $ pbdistrocheck distro tuple: mandriva,2009.0,md,rpm,.mdv2009.0,sudo urpmi.update -a ; sudo urpmi --auto > Since we already did a 4.1 "release" (almost one year ago) and > a set of packages, I'll rev the current HEAD to tag v4_2 and do > another set of tar.gz/packages (using Bruno's project-builder), > then move HEAD to start generating 4.3 for all the upcoming > snapshots/work. Feel free to ask for help in your pb setup. You're my most advanced user (at least I think ;-) so I want that it goes smoothly for you. Bruno. -- Linux Profession Lead EMEA / Open Source Ambassador \ EMEA CME SoL. Center http://www.mondorescue.org / HP/Intel Solution Center \ http://hpintelco.net Des infos sur Linux? http://www.HyPer-Linux.org http://www.hp.com/linux La musique ancienne? http://www.musique-ancienne.org http://www.medieval.org |
|
From: Bryan G. <bry...@hp...> - 2009-02-23 23:49:00
|
Bruno,
On Mon, Feb 23, 2009 at 04:44:06PM +0000, Cornec, Bruno (Open Source and Linux Technology Architect) wrote:
> > My current plan is to create all of our items using lsb_release -a output
> > as the standard.
>
> Interesting. On my Mandriva distro it gives:
>
> LSB Version: lsb-3.1-amd64:lsb-3.1-noarch:*
> Distributor ID: MandrivaLinux
> Description: Mandriva Linux 2009.0
> Release: 2009.0
> Codename: zarapha
>
> However, the lsb package is optional on most distro. And then, it uses
> .etc.distro-release, except on Debian where it doesn't exist ;-)
Actually I mean that I'll "name" all of our config files according
to this "standard", not that I'll actually run lsb_release on the
LinuxCOE SystemDesigner host nor on any target (designed) system.
My proposed naming guideline will be:
<lsb_release -s -i>-<lsb_release -s -r>-<uname -m>
Distributor ID - Release - machine hardware name
since all the LSB supported distros will have to have that namespace
already approved/vetted. Sure I'll have to deal with those
distributions that don't deliver lsb_release, but certainly for the
set we are supporting that will be a small exception set basis (since
all already do).
> Interesting to see that I arrived at a similar solution, but not
> requiring the lsb package to be present in my pbdistrocheck package.
> I'll submit it to CPAN now that I have an account BTW.
>
> $ pbdistrocheck
> distro tuple: mandriva,2009.0,md,rpm,.mdv2009.0,sudo urpmi.update -a ; sudo urpmi --auto
Good that you ended up in a similar state. But at this point I have no
need to distribute *any* tool to calculate this, but only to run it once
on a given "tuple" to generate what should be used. If we do later
get to this point, perhaps when we migrate to using something like
Config::Model, it would be important to calculate a value (perhaps
via the pbdistrocheck) and generate all the config files automatically.
> > Since we already did a 4.1 "release" (almost one year ago) and
> > a set of packages, I'll rev the current HEAD to tag v4_2 and do
> > another set of tar.gz/packages (using Bruno's project-builder),
> > then move HEAD to start generating 4.3 for all the upcoming
> > snapshots/work.
>
> Feel free to ask for help in your pb setup. You're my most advanced user
> (at least I think ;-) so I want that it goes smoothly for you.
You know I will. I am still having some fundamental startup questions,
adjusting .pbrc values to the appropriate settings, and also doing first
run kinds of cms2build operations (from scratch). I'll contact you
directly with these questions,
bryang
|
|
From: Bruno C. <Bru...@hp...> - 2009-02-24 17:04:57
|
Bryan Gartner said on Mon, Feb 23, 2009 at 04:48:55PM -0700: > My proposed naming guideline will be: > > <lsb_release -s -i>-<lsb_release -s -r>-<uname -m> > Distributor ID - Release - machine hardware name My only warning here is that there may be (not completely sure) differences between what gives lsb_release -s -i and lsb_release -s -r and what is contained in the /etc/distro-release file. I have not checked it. > > $ pbdistrocheck > > distro tuple: mandriva,2009.0,md,rpm,.mdv2009.0,sudo urpmi.update -a ; sudo urpmi --auto > > Good that you ended up in a similar state. But at this point I have no > need to distribute *any* tool to calculate this, Well you need the lsb package installed. Which is not by default on most distro. But agreed with you. What I was proposing is that you could call also the perl module ProjectBuilder::Distribution and integrate it in your delivery directly. That way you're autonomous. > but only to run it once > on a given "tuple" to generate what should be used. If we do later > get to this point, perhaps when we migrate to using something like > Config::Model, it would be important to calculate a value (perhaps > via the pbdistrocheck) and generate all the config files automatically. True. > You know I will. I am still having some fundamental startup questions, > adjusting .pbrc values to the appropriate settings, and also doing first > run kinds of cms2build operations (from scratch). I'll contact you > directly with these questions, Thanks for your patience on this. My ability to document is worse that mine to code ;-) But I'll try to improve the wiki soon with examples made from scratch so that people could at least follow those instructions to setup an environement. Bruno. -- Linux Profession Lead EMEA / Open Source Ambassador \ EMEA CME SoL. Center http://www.mondorescue.org / HP/Intel Solution Center \ http://hpintelco.net Des infos sur Linux? http://www.HyPer-Linux.org http://www.hp.com/linux La musique ancienne? http://www.musique-ancienne.org http://www.medieval.org |
|
From: Bryan G. <bry...@hp...> - 2009-03-12 12:58:15
|
FYI,
I'm going to go ahead and get ready to snapshot our current bits
as a 4.2 release here shortly, complete with packages, etc.
But as a follow-on to this to thread (and for our 4.3 development),
I have taken an RFC-ish stab (albeit certainly not completely thought
through nor implemented) at a new format for our distmap file to
accomplish this. At a minimum, we'd need some perl code/library
to parse (and maybe even create entries), which we could hopefully
re-use for some other related projects.
Nothing is sacred in this proposal, and modifications to make the
coding/API/access easier is all fair game.
OSVendKeyword Tag = {EquivalentList(AlsoKnownAsList)}
^ ^ ^
distro | list of lists
version |
arch |
value
(assumedly, we'd do lower case shift for all internal
code comparisons)
and can reference next higher level of hierarchy
distro = distroA
version distroA = ver1
arch ver1 =
An ability to wildcard or * case would also be nice (like for
aliasing amd64 <-> x86_64).
Hear are some example entries:
----------------------------------- cut here -----------------------------------
distro Debian = debian
version Debian = sid(unstable),woody(3.0),sarge(3.1),etch(4.0),lenny(stable,5.0),squeeze(testing,6.0), ...
arch Debian = amd64(x86_64),hppa(parisc),i386(i486,i586,i686)
----------------------------------- cut here -----------------------------------
distro RedHat = redhat,RedHatEnterpriseServer,RedHatEnterpriseClient,RedHatEnter
priseWS, ...
version RedHat = 2.1AS,2.1ES,2.1WS,3.0AS,3.0AS-U1, ..., 4AS,4AS-U1, ..., 5Server,5.1
Server, ..
version RedHatEnterpriseWS = 4
version RedHatEnterpriseServer = 5,5.1,5.2,5.3(Tikanga) ...
version RedHatEnterpriseClient = 5,5.1,5.2, ...
arch RedHat = i386, x86_64, ia64
|
|
From: Bruno C. <Bru...@hp...> - 2009-03-16 19:22:06
|
Hello Bryan, Bryan Gartner said on Thu, Mar 12, 2009 at 06:57:14AM -0600: > But as a follow-on to this to thread (and for our 4.3 development), > I have taken an RFC-ish stab (albeit certainly not completely thought > through nor implemented) at a new format for our distmap file to > accomplish this. At a minimum, we'd need some perl code/library > to parse (and maybe even create entries), which we could hopefully > re-use for some other related projects. Probably we could use what I began to write at http://trac.project-builder.org/browser/devel/pb-modules/lib/ProjectBuilder/Distribution.pm > distro Debian = debian > version Debian = sid(unstable),woody(3.0),sarge(3.1),etch(4.0),lenny(stable,5.0),squeeze(testing,6.0), ... > arch Debian = amd64(x86_64),hppa(parisc),i386(i486,i586,i686) I'd like to extend the proposal to add some additional info I need on my side, and that could also fit here: pkgtype Debian = deb pkgtype Ubuntu = deb pkgtype Fedora = rpm pkgtype Mandriva = rpm pkgtype OpenSuSE = rpm family Debian = du family Ubuntu = du (manages all debian-ubuntu aka du distro the same way wrt packages) family Fedora = rh family RedHat = rh (manages all these distro the same way wrt packages) Also: update Debian = sudo apt-get install update Fedora = sudo yum -y install ... I'm also needing the extension for packages, but could be added later on. How can I help with this Bryan ? Bruno. -- Linux Profession Lead EMEA / Open Source Ambassador \ EMEA CME Sol. Center http://www.mondorescue.org / HP/Intel Solution Center \ http://hpintelco.net Des infos sur Linux? http://www.HyPer-Linux.org http://www.hp.com/linux La musique ancienne? http://www.musique-ancienne.org http://www.medieval.org |
|
From: Bryan G. <bry...@hp...> - 2009-05-18 17:38:30
|
FYI, On Thu, Mar 12, 2009 at 12:57:14PM +0000, Gartner, Bryan W wrote: > But as a follow-on to this to thread (and for our 4.3 development), > I have taken an RFC-ish stab (albeit certainly not completely thought > through nor implemented) at a new format for our distmap file to > accomplish this. At a minimum, we'd need some perl code/library > to parse (and maybe even create entries), which we could hopefully > re-use for some other related projects. Okay, so vastly redone, as usually happens when you actually have to implement it. For now, I've taken a stab at: DistMap.pm # three modules parser - simple reader dump - simple output format stack - create a simple perl stack/list from least specific to most specific, with all the AKA (also known as) DistMap.cf # example configuration file, with formatting comments distmap.pl # simple caller that demonstrates the three modules These are checked into SystemDesigner-contrib for your further review and feedback. bryang |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X