9:37 a.m.
Hallo list again,
I just did my self-introduction and immediately I have my first
questions:
1.
If I want to announce and provide the packages which I produced, is
it necessary to set up a special directory tree on my server
(something like fedora/2/i386/RPMS.unstable etc.) where the packages
are made available for download?
2.
I am not sure about the right Fedora tree for my packages. Most of
them are stable in my opinion and could placed in testing but since
these are my first Fedora packages I am thinking about to place them
in unstable for the start. What do you think?
3.
I don't know which official group I should use. For the libraries
this is rather easy. But I don't what to do with GIS software
(perhaps Applications/Productivity). It is even more difficult with
geodata. They don't seem to fit to any group of RH (s.
http://www.fedora.us/wiki/RPMGroups). Any idea?
Ciao,
Silke
--
Silke Reimer
Intevation GmbH http://intevation.de/
FreeGIS http://freegis.org/
10:07 a.m.
Silke Reimer wrote:
Hallo list again,
I just did my self-introduction and immediately I have my first
questions:
1.
If I want to announce and provide the packages which I produced, is
it necessary to set up a special directory tree on my server
(something like fedora/2/i386/RPMS.unstable etc.) where the packages
are made available for download?
2.
I am not sure about the right Fedora tree for my packages. Most of
them are stable in my opinion and could placed in testing but since
these are my first Fedora packages I am thinking about to place them
in unstable for the start. What do you think?
3.
I don't know which official group I should use. For the libraries
this is rather easy. But I don't what to do with GIS software
(perhaps Applications/Productivity). It is even more difficult with
geodata. They don't seem to fit to any group of RH (s.
http://www.fedora.us/wiki/RPMGroups). Any idea?
Ciao,
Silke
Check out the QA and Submission policy link at www.fedora.us:
http://www.fedora.us/wiki/PackageSubmissionQAPolicy
HTH
Neil
--
/***************************************************
*Neil Horman
*Software Engineer
*Red Hat, Inc.
*nhorman(a)redhat.com
*gpg keyid: 1024D / 0x92A74FA1
*http://pgp.mit.edu
***************************************************/
10:31 a.m.
On Fri, Aug 06, 2004 at 11:07:51AM -0400, Neil Horman wrote:
Silke Reimer wrote:
>Hallo list again,
>
>I just did my self-introduction and immediately I have my first
>questions:
>
>1.
>If I want to announce and provide the packages which I produced, is
>it necessary to set up a special directory tree on my server
>(something like fedora/2/i386/RPMS.unstable etc.) where the packages
>are made available for download?
>
>2.
>I am not sure about the right Fedora tree for my packages. Most of
>them are stable in my opinion and could placed in testing but since
>these are my first Fedora packages I am thinking about to place them
>in unstable for the start. What do you think?
>
>3.
>I don't know which official group I should use. For the libraries
>this is rather easy. But I don't what to do with GIS software
>(perhaps Applications/Productivity). It is even more difficult with
>geodata. They don't seem to fit to any group of RH (s.
>http://www.fedora.us/wiki/RPMGroups). Any idea?
>
>Ciao,
>
> Silke
>
>
>
Check out the QA and Submission policy link at www.fedora.us:
http://www.fedora.us/wiki/PackageSubmissionQAPolicy
OK. This does help for point 1. Sorry for asking this stupid
question. But I still don't know what to do with 2. and 3. Of course
I could let this open for the QA-people but I think it does make
sense to fill in the right values from the very beginning.
Thanks,
Silke
--
Silke Reimer
Intevation GmbH http://intevation.de/
FreeGIS http://freegis.org/
10:37 a.m.
Silke Reimer wrote:
On Fri, Aug 06, 2004 at 11:07:51AM -0400, Neil Horman wrote:
>Silke Reimer wrote:
>
>>Hallo list again,
>>
>>I just did my self-introduction and immediately I have my first
>>questions:
>>
>>1.
>>If I want to announce and provide the packages which I produced, is
>>it necessary to set up a special directory tree on my server
>>(something like fedora/2/i386/RPMS.unstable etc.) where the packages
>>are made available for download?
>>
>>2.
>>I am not sure about the right Fedora tree for my packages. Most of
>>them are stable in my opinion and could placed in testing but since
>>these are my first Fedora packages I am thinking about to place them
>>in unstable for the start. What do you think?
>>
>>3.
>>I don't know which official group I should use. For the libraries
>>this is rather easy. But I don't what to do with GIS software
>>(perhaps Applications/Productivity). It is even more difficult with
>>geodata. They don't seem to fit to any group of RH (s.
>>http://www.fedora.us/wiki/RPMGroups). Any idea?
>>
>>Ciao,
>>
>> Silke
>>
>>
>>
>
>Check out the QA and Submission policy link at www.fedora.us:
>http://www.fedora.us/wiki/PackageSubmissionQAPolicy
OK. This does help for point 1. Sorry for asking this stupid
question. But I still don't know what to do with 2. and 3. Of course
I could let this open for the QA-people but I think it does make
sense to fill in the right values from the very beginning.
Thanks,
Silke
They aren't stupid questions. :)
2) I think its best left up to you. QA people will comment on what they
think about you're decision when you submit the package. If you aren't
sure as to the stability of your package, I'd put it in unstable. Move
it later, when you feel its ready.
3) I think Applications/Productivity is a fine place to put GIS
software, but again, your decision.
Neil
--
/***************************************************
*Neil Horman
*Software Engineer
*Red Hat, Inc.
*nhorman(a)redhat.com
*gpg keyid: 1024D / 0x92A74FA1
*http://pgp.mit.edu
***************************************************/
6:47 p.m.
New subject: RPMGroups -- time to refresh? [was Re: Question about how to announce packages]
Actually, I think it's an excellent question to ask how things like this
(and related subjects) should be organized. I don't think we should be
stuck with categorizations that were defined, by fiat, 5+ years ago.
Much has happened, and a good (better?) characterization tree might be a
good thing for a near-term version of Fedora. Eric Raymond has spoken
that he'd like to present the Trove (http://www.catb.org/~esr/trove/).
I for one think it might be useful to find some happy medium between the
obviously small number of groups defined by
http://www.fedora.us/wiki/RPMGroups, the large number defined by the
Trove, those defined implicitly and explicitly by ibiblio, etc. I don't
want this to confound the discussion about how Fedora Collections might
be defined, but I do think that a proper hierarchy of functionality
would help both the archivists, collectors, and applicators of open
source technologies.
M
On Fri, 2004-08-06 at 11:37, Neil Horman wrote:
Silke Reimer wrote:
> On Fri, Aug 06, 2004 at 11:07:51AM -0400, Neil Horman wrote:
>
>>Silke Reimer wrote:
>>
>>>Hallo list again,
>>>
>>>I just did my self-introduction and immediately I have my first
>>>questions:
>>>
>>>1.
>>>If I want to announce and provide the packages which I produced, is
>>>it necessary to set up a special directory tree on my server
>>>(something like fedora/2/i386/RPMS.unstable etc.) where the packages
>>>are made available for download?
>>>
>>>2.
>>>I am not sure about the right Fedora tree for my packages. Most of
>>>them are stable in my opinion and could placed in testing but since
>>>these are my first Fedora packages I am thinking about to place them
>>>in unstable for the start. What do you think?
>>>
>>>3.
>>>I don't know which official group I should use. For the libraries
>>>this is rather easy. But I don't what to do with GIS software
>>>(perhaps Applications/Productivity). It is even more difficult with
>>>geodata. They don't seem to fit to any group of RH (s.
>>>http://www.fedora.us/wiki/RPMGroups). Any idea?
>>>
>>>Ciao,
>>>
>>> Silke
>>>
>>>
>>>
>>
>>Check out the QA and Submission policy link at www.fedora.us:
>>http://www.fedora.us/wiki/PackageSubmissionQAPolicy
>
>
> OK. This does help for point 1. Sorry for asking this stupid
> question. But I still don't know what to do with 2. and 3. Of course
> I could let this open for the QA-people but I think it does make
> sense to fill in the right values from the very beginning.
>
> Thanks,
>
> Silke
>
>
They aren't stupid questions. :)
2) I think its best left up to you. QA people will comment on what they
think about you're decision when you submit the package. If you aren't
sure as to the stability of your package, I'd put it in unstable. Move
it later, when you feel its ready.
3) I think Applications/Productivity is a fine place to put GIS
software, but again, your decision.
Neil
--
/***************************************************
*Neil Horman
*Software Engineer
*Red Hat, Inc.
*nhorman(a)redhat.com
*gpg keyid: 1024D / 0x92A74FA1
*http://pgp.mit.edu
***************************************************/
6:51 p.m.
New subject: RPMGroups -- time to refresh? [was Re: Question about how to announce packages]
On Sun, 2004-08-08 at 19:47 -0400, Michael Tiemann wrote:
Actually, I think it's an excellent question to ask how things
like this
(and related subjects) should be organized. I don't think we should be
stuck with categorizations that were defined, by fiat, 5+ years ago.
Much has happened, and a good (better?) characterization tree might be a
good thing for a near-term version of Fedora. Eric Raymond has spoken
that he'd like to present the Trove (http://www.catb.org/~esr/trove/).
I for one think it might be useful to find some happy medium between the
obviously small number of groups defined by
http://www.fedora.us/wiki/RPMGroups, the large number defined by the
Trove, those defined implicitly and explicitly by ibiblio, etc. I don't
want this to confound the discussion about how Fedora Collections might
be defined, but I do think that a proper hierarchy of functionality
would help both the archivists, collectors, and applicators of open
source technologies.
I think for the purposes of core and to some extent for collections w/i
extras we'll need some way of describing groups comprised of specific
packages. This is what comps.xml has done for a while for rhl/fc but
comps needs to be freshened up a bit to include:
- archs (sorry jeremy)
- possibly partial or complete versions
- more granularity of group requirement
This is part of the discussion we've had wrt to the xml metadata for rpm
repositories.
This works not from w/i the package but from the outisde, of course, and
it would allow a per-repository basis to describe groups of packages.
-sv
7:48 p.m.
New subject: RPMGroups -- time to refresh? [was Re: Question about how to announce packages]
On Sun, 08 Aug 2004 19:51:48 -0400, seth vidal <skvidal(a)phy.duke.edu> wrote:
I think for the purposes of core and to some extent for collections
w/i
extras we'll need some way of describing groups comprised of specific
packages. This is what comps.xml has done for a while for rhl/fc but
comps needs to be freshened up a bit to include:
- archs (sorry jeremy)
- possibly partial or complete versions
- more granularity of group requirement
This is part of the discussion we've had wrt to the xml metadata for rpm
repositories.
This works not from w/i the package but from the outisde, of course, and
it would allow a per-repository basis to describe groups of packages.
This is a really complicated issue. I've had several versions of this
argument with several different people. I of course, being the evil
sob that i am, have taken different sides of the argument at different
times.
Right now I see at a mimimum 3 different explict package groupings
being used inside the distribution:
1) rpm group tag
2) comps.xml
3) The applications menu structure.
Right now each one of these ways of organizing packages serves different uses.
comps.xml and similiar is clearly targetted as a way to help people
install bundles of packages for large chunks of 'recommended'
functionality. If we really want to talk about a future where
community can redefine collections inside Fedora, something as
flexible as comps.xml must continue to exist to allow for people to
play with alternative ways to groups packages outside the strict
dependencies inside a package. Right now, I would say comps.xml
isn't being used so well as a way to browse individual packages for
install or for removal. Because the comps.xml approach is very
flexible and multiple repositories can layer their groupings, i can't
imagine it would be all that difficult to build an alternative
comps.xml that represented several trove like views to make browsing
packages for different criteria easier.
Right now the applications menu organization is different than both
rpm group tag and comps.xml. I fear that continual debate about how
to name menu items is going to lead to a continual disconnect between
the strings in comps.xml and the textual listings in the menus. I
think there is room here to build an alternate comps.xml that mimiced
the applications menu groupings as a useful tool for users. Want to
find a specific graphics application or system tool? Use the comps.xml
that groups applications exactly like the application menus structure
so you can browse the application menu structure looking for
applications. With enough tequila.. i can even imagine some sort of
tool that could automate generation of a applications menu mimic that
took into account local menu structure changes.
rpm group tag currently is a search for package by package
functionality. You can ask questions like 'what are all the libraries
packages installed on my system.' Well okay to be honest the rpm
group tag current doesn't serve much of a use at all, very rudimentry
search by function really. The rpm group tag formatting/syntax would
have to be greatly expanded to be useful as a fine grained searching.
And even then its a nightmare to think about if you are going to allow
for locale specific strings....a nightmare. And sort of comps.xml file
approach to trove listing creation will be able to provide for locale
specific listings.
-jef
9:07 a.m.
New subject: RPMGroups -- time to refresh? [was Re: Question about how to announce packages]
On Sun, 2004-08-08 at 20:48, Jeff Spaleta wrote:
On Sun, 08 Aug 2004 19:51:48 -0400, seth vidal
<skvidal(a)phy.duke.edu> wrote:
> I think for the purposes of core and to some extent for collections w/i
> extras we'll need some way of describing groups comprised of specific
> packages. This is what comps.xml has done for a while for rhl/fc but
> comps needs to be freshened up a bit to include:
> - archs (sorry jeremy)
> - possibly partial or complete versions
> - more granularity of group requirement
>
> This is part of the discussion we've had wrt to the xml metadata for rpm
> repositories.
>
> This works not from w/i the package but from the outisde, of course, and
> it would allow a per-repository basis to describe groups of packages.
This is a really complicated issue. I've had several versions of this
argument with several different people. I of course, being the evil
sob that i am, have taken different sides of the argument at different
times.
Right now I see at a mimimum 3 different explict package groupings
being used inside the distribution:
1) rpm group tag
2) comps.xml
3) The applications menu structure.
Right now each one of these ways of organizing packages serves different uses.
comps.xml and similiar is clearly targetted as a way to help people
install bundles of packages for large chunks of 'recommended'
functionality. If we really want to talk about a future where
community can redefine collections inside Fedora, something as
flexible as comps.xml must continue to exist to allow for people to
play with alternative ways to groups packages outside the strict
dependencies inside a package. Right now, I would say comps.xml
isn't being used so well as a way to browse individual packages for
install or for removal. Because the comps.xml approach is very
flexible and multiple repositories can layer their groupings, i can't
imagine it would be all that difficult to build an alternative
comps.xml that represented several trove like views to make browsing
packages for different criteria easier.
Is comps.xml really that great? One problem it seems to have is that is
must constantly be kept up to date with the latest package revisions.
Wouldn't it be better to keep the group tag in the RPMs themselves
(possibly replacing the fairly useless group field in there now), and
let the comps.xml format merely override those for users with special
cases?
Then the comps.xml for Fedora Core might not change much at all; if a
new package is uploaded to the repository and is tagged as, say, being a
core GNOME app, it'll Just Work(tm).
rpm group tag currently is a search for package by package
functionality. You can ask questions like 'what are all the libraries
packages installed on my system.' Well okay to be honest the rpm
group tag current doesn't serve much of a use at all, very rudimentry
search by function really. The rpm group tag formatting/syntax would
have to be greatly expanded to be useful as a fine grained searching.
In this case, I think it would be a _lot_ better to just add a tag like
"PackageType." It would be one of: library, application, tool, data,
documentation, debuginfo, development, core, etc.
If you then also added a tag like "RelevantTo:", you could mark all
documentation/debuginfo/development/data packages as relevant to the
particular application/tool/library packages, so you can do neat things
like ask the system to install all debuginfo packages for every package
already installed, remove all documentation packages, etc.
You can also do some nifty policy work. For example, ask yum to always
try to Install vs Upgrade library packages. One thing that's incredibly
retarded in Fedora is the way library packages with incompatible
versions of the library (and with different sonames even) always want to
upgrade the old package. You are forced to constantly keep all
applications using the library in sync, which is just dumb. Especially
when upstream may not have migrated to an API update. Having to rename
packages a la Debian is a lot of work, if library packages were just
Installed instead of Upgraded, things should just work in most cases.
Being able to make that kind of policy in the client side without having
to go repackage the entire distribution would make life a lot easier
both in testing and in actual usage.
And even then its a nightmare to think about if you are going to
allow
for locale specific strings....a nightmare. And sort of comps.xml file
approach to trove listing creation will be able to provide for locale
specific listings.
-jef
--
Sean Middleditch <elanthis(a)awesomeplay.com>
AwesomePlay Productions, Inc.
4:15 p.m.
On Fri, Aug 06, 2004 at 04:37:49PM +0200, Silke Reimer wrote:
2.
I am not sure about the right Fedora tree for my packages. Most of
them are stable in my opinion and could placed in testing but since
these are my first Fedora packages I am thinking about to place them
in unstable for the start. What do you think?
Pick whatever makes sense for the software itself. The QA people will
more than make up any packaging deficiencies, I'm sure. :-)
Steve
--
Steven Pritchard - K&S Pritchard Enterprises, Inc.
Email: steve(a)kspei.com http://www.kspei.com/
Phone: (618)398-7360 Mobile: (618)567-7320
7223
days inactive
7226
days old
8 comments
7 participants
participants (7)
-
Jef Spaleta -
Michael Tiemann -
Neil Horman -
Sean Middleditch -
seth vidal -
Silke Reimer -
Steven Pritchard