> Hi
>
> While fixing our testsuite to run with PhantomJS, we hit a clunky
> part:
>
> - One is that when adding a channel, default checksum is sha1, parent
> channel None. But:
> - Changing the parent channel, triggers changing the checksum /
> arch
> to the parent channel one
> - Except if you select Parent: None again, Checksum will be None
> (and
> not sha1) -> BUG (and we can fix it and make a PR)
>
> So to fix that bug, we found out that a None checksum makes
> taskomatic
> silently skip that channel for metadata generation which could be
> very
> confusing for users:
Duncan,
what you describe this is a feature that works as designed. :-)
RHEL4 clients and older used up2date instead of yum. And all the dependency
resolution wasn't done on the client, but on the server.
That's why no repodata was needed to generate for these channels.
'bad repo' was implemented to let the user know, there is no intention to
generate proper repodata and to say - we did not forget to generate
repodata for this channel as someone could have assumed.
And the 'none' checksum was used to mark these channels.
If this code bothers you and taking into consideration RHEL4 is EOL, we do not
need that code any more.
Feel free to create a PR, we're open to remove the code.
Regards,
--
Tomas Lestach
Red Hat Satellite Engineering, Red Hat
>
> if (checksumtype == null) {
> generateBadRepo(channel, prefix);
> return;
> }
>
> So I was thinking to add a better log entry and may be a warning in
> the
> channel details page, but...
>
> If we don't generate metadata for "None", and this option is not part
> of
> checksumtype table, but manually added in the form:
>
> List<Map<String, String>> checksums = new ArrayList<Map<String,
> String>>();
> addOption(checksums, ls.getMessage("generic.jsp.none"), "");
> for (ChecksumType chType :
> ChannelFactory.listYumSupportedChecksums()) {
> addOption(checksums, chType.getLabel(),
> chType.getLabel());
> }
>
> Why not removing the "None" option alltogether? Does anyone see a
> reason
> to keep it?
>
> Regards,
>
> --
> Duncan Mac-Vicar P. - http://www.suse.com/
>
> SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Dilip Upmanyu,
> Graham Norton, HRB 21284 (AG Nürnberg)
> Maxfeldstraße 5, 90409 Nürnberg, Germany
>
>
>
>
> _______________________________________________
> Spacewalk-devel mailing list
> Spacewalk-devel@redhat.com
> https://www.redhat.com/mailman/listinfo/spacewalk-devel
_______________________________________________
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel
