Bug 885151 - [BUG] kickstart repo --name cannot have spaces or the repo will not be added
Summary: [BUG] kickstart repo --name cannot have spaces or the repo will not be added
Keywords:
Status: CLOSED EOL
Alias: None
Product: Fedora
Classification: Fedora
Component: anaconda
Version: 19
Hardware: Unspecified
OS: Unspecified
unspecified
medium
Target Milestone: ---
Assignee: rmarshall
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: RejectedBlocker AcceptedFreezeException
: 886868 (view as bug list)
Depends On:
Blocks: F19-accepted, F19FinalFreezeException
TreeView+ depends on / blocked
 
Reported: 2012-12-07 15:44 UTC by Bill Peck
Modified: 2015-02-17 14:36 UTC (History)
16 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-02-17 14:36:26 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
packaging.log (6.07 KB, text/plain)
2012-12-10 19:21 UTC, Samantha N. Bueno
no flags Details

Description Bill Peck 2012-12-07 15:44:16 UTC
Description of problem:
The following kickstart directive used to work with Fedora17, but fails now with 18.


repo --name="RPM Fusion for Fedora 18 - Free" --baseurl=http://download1.rpmfusion.org/free/fedora/development/18/x86_64/os/

Any --name parameter which includes a space will fail.  

Work around is to replace spaces with _.

Version-Release number of selected component (if applicable):
18.35

How reproducible:
Every time

Steps to Reproduce:
1. Install with kickstart and include repo --name="one two" --url=http://valid/repo
2. include package which is only in repo
  
Actual results:
Install will complain that package is not available.

Expected results:
Install will install package from additional repo with spaces in it.

Comment 1 Samantha N. Bueno 2012-12-10 19:20:50 UTC
Looks like this problem lies within yum, not anaconda. I'm no yum expert, but it looks like the getGroups function in yumRepo.py might be the culprit; reassigning to the appropriate component.

I'll also attach packaging.log from when I reproduced this following the steps in the original post.

Comment 2 Samantha N. Bueno 2012-12-10 19:21:26 UTC
Created attachment 661030 [details]
packaging.log

Comment 3 Chris Lumens 2012-12-13 15:21:45 UTC
*** Bug 886868 has been marked as a duplicate of this bug. ***

Comment 4 Bill Peck 2013-05-31 17:56:00 UTC
This is *still* broken in the latest Fedora 19 build.

Comment 5 Zdeněk Pavlas 2013-06-12 13:09:05 UTC
While repository NAME can contain spaces in Yum, the repo ID can not(*).  Also, the ID is mandatory, and NAME is optional.  I guess kickstart breaks these rules (probably setting the ID to be equal to NAME).  Is there an --id option to set the repo ID explicitly?

IMO, this is a bug in kickstart.. It should use the specified repo ID, or auto-generate a valid one (eg ks001, ks002 etc).  Have no idea why this worked in F17 (the repo ID check is from year 2008).

(*)Allowed repo ID chars are ascii letters, numbers, and "-_.:".

Comment 6 Bill Peck 2013-06-12 13:40:53 UTC
Here is a link to the kickstart repo command

http://fedoraproject.org/wiki/Anaconda/Kickstart#repo

The argument is called --name but the description says "the repoid".  

This is confusing. :-)

At a minimum the doc should be updated with a list of acceptable chars, or maybe automatically replace spaces with _?

Comment 7 Adam Williamson 2013-06-12 17:12:42 UTC
Discussed at 2013-06-12 blocker review meeting: http://meetbot.fedoraproject.org/fedora-blocker-review/2013-06-12/f19final-blocker-review-5.2013-06-12-16.01.log.txt . This was rejected as a blocker bug as it doesn't really violate any release criteria and is easy enough to work around, but accepted as a freeze exception issue: it seems like improvements could be made to this anaconda-side if the anaconda team felt it was appropriate, like converting spaces to underscores in the repo ID, or just failing with a more useful error message. So we're re-assigning to anaconda for their decision: if they think the code is fine and the docs should just be updated, that's of course up to them, but we're giving them the option of putting a reasonable code fix in.

Comment 8 Fedora End Of Life 2015-01-09 17:31:05 UTC
This message is a notice that Fedora 19 is now at end of life. Fedora 
has stopped maintaining and issuing updates for Fedora 19. It is 
Fedora's policy to close all bug reports from releases that are no 
longer maintained. Approximately 4 (four) weeks from now this bug will
be closed as EOL if it remains open with a Fedora 'version' of '19'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 19 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 9 Fedora End Of Life 2015-02-17 14:36:26 UTC
Fedora 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.


Note You need to log in before you can comment on or make changes to this bug.