On Fri, Feb 26, 2016 at 08:33:10AM -0500, Honza Šilhan wrote:
> From: "Dennis Gilmore" <dennis(a)ausil.us>
>
> I have unpushed from f24 and rawhide dnf-1.1.7-1 and revoked the requests for
> updates. The main reason being that the api changed ina way that broke our
> ability to create install media.
>
> lorax --product=Fedora --version=24 --release=24
> --source=file:///mnt/koji/compose/branched/Fedora-24-20160225.n.0/work/i386/repo
> --variant=Workstation --nomacboot --noupgrade --buildarch=athlon
> --volid=Fedora-WS-boot-i386-24 --installpkgs=fedora-productimg-workstation
>
/mnt/koji/compose/branched/Fedora-24-20160225.n.0/work/i386/buildinstall/Workstation
> 2016-02-25 16:46:06,909: Added 'lorax-repo-0':
> ...
> self.basearch = dnf.arch.basearch(buildarch)
> AttributeError: module 'dnf' has no attribute 'arch'
>
> An API change like that is a point release is not acceptable, certainly not
> without working With the users of the code to ensure that you do not break
> peoples code. Given where we are in the Fedora 24 cycle where we need to be
> reliably composing the OS in order to have a Alpha compose in a few short
> weeks.
That was no API change, `basearch` function was actually introduced in this release
[1][2].
Lorax guys, can you adapt lorax, please?
"self.basearch = dnf.arch.basearch(buildarch)" -> "self.basearch =
dnf.rpm.basearch(buildarch)"
Keep in touch with me via IRC (jsilhan on #fedora-releng) when you are awake so we can
find
the best solution for this issue.
Also double check what non DNF API functions are you using. If you want them to be added
into API,
file the bug for DNF and we will happily document it. We would like to not get back to
yum age
where no API existed and every tools was calling whatever they liked.
Whenever we break API it's in the next major release only while providing patches to
the consumers we
know about.
Paradoxically, this was exposed on relengs demand - to add custom arch support for
repoclosure. This will be needed for F23.
Thanks,
Honza
[1]
http://dnf.readthedocs.org/en/latest/release_notes.html#release-notes
[2]
http://dnf.readthedocs.org/en/latest/api_rpm.html#dnf.rpm.basearch
This code was in a top level module and was not marked with _ as is
the python convention for private methods. Whether or not you document
the api is immaterial. If you expose a method it is going to eventually
get used by someone.
See
https://www.python.org/dev/peps/pep-0008/#public-and-internal-interfaces
for the correct way to manage exposing public methods (eg. use of
__all__ and _)
Also, it is pretty clear that this method is in use by dnf users. It
would be far better if you added arch.py with a deprecation warning
instead of insisting that all your users rewrite their code across 4
releases.
--
Brian C. Lane | Anaconda Team | IRC: bcl #anaconda | Port Orchard, WA (PST8PDT)