On Tue, Feb 04, 2014 at 11:54:13AM +0100, Milan Zázrivec wrote:
> Using "myfantasticserver" and {"name" : "alsa-lib", "version" : "1.0.22",} to
> identify server and package? Please no.

How do you remove an orphan package that is not on the channels from the
particular machine? The UI allows to do that, but the package is identified by
NEVRA (well, by a combo, which it is).

Having this API already working, logically you would like to extend that
elsewhere, even if it is an additional API.

> It's not uncommon to have the same machine registered with Spacewalk multiple
> times and use the same profile name / hostname / IP address for all these
> registrations. "myfantasticserver" simply won't be enough to uniquely identify
> the desired server -- only server id will be.
> 
> Similarly, it's perfectly OK to have two packages with the same NEVRA pushed
> into one organization (for example RHEL + CentOS). In these situations, your
> concept would not be able to realiably identify desired packages -- only 
> package id would be.

But I would expect two packages would either have different checksum and/or in
different channels?

> While I understand that the thought of operating with human-compatible data
> seems appealing, I'm afraid it won't work with API, where we need to model
> functions in an orthogonal manner -- i.e. one function will give you system
> id(s), another one will give you package id(s) and a third one will take these
> two ids and instruct a specific chain to remove packages from a specific
> system.

This are three calls. Fine with the software, like we've built for Android
for example, but quite bad if this is your admin script.

Leaving the "by ID" still available, isn't it better to have a convenience
layer by name?

-- 
Bo Maryniuk

SUSE LINUX Products GmbH, HRB 16746 (AG Nürnberg)
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer

A positive attitude may not solve all your problems,
but it will annoy enough people to make it worth the effort.

_______________________________________________
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel

Reply via email to