I'll try to reply both mails within this one.
Regarding the multiple architectures repos and DVD, i also thought
about just don't support
them. But I wanted to check if they may fit in some manner. As I
understand, a single distro
can have multiple profiles (with different ks), so it might be more or
less ready to support
multiple architectures (a different pxe config + ks).
The default preseed is on the close future list, though I want to have
a closer look into how
kickstarts are managed. And the repo managemen will hopefully be easy,
as the only tool
I know to mirror debian repositories is already written in python (debmirror).
First off, thanks very much for the patch. The first one is going
to
need a minor bit of tweaking to put the constants back to the way
Cobbler used them, though the generalized code cleanup is a good in
priciple -- I do not want the constants renumbered or mapped to provide
aliases for one another. I'll explain why. I had thought you were
wanting to rewrite this more than what you had submitted.
Both the "canonical" and the map lists were initially internal variables for
import. But I saw that the "wrong" names were used in other places (specially
on pxegen, which brokes the consistency, I decided to move into utils package,
to made it widely available. The map is actually intended only to map
architecture
names from files and directories into the canonical names, so it should be
internal to import, but I moved also into utils because it might be useful
for serializers in order to ensure the arch names in the files become the
canonical ones. In the mid-long term, the map should go again into
import, unless other cobbler part need non user supplied architectures.
Ok, so the reason we have consolidated on x86 and x86_64 (not i386
or
i686) is to ensure that we don't break things unexpectedly with respect
to yum. There i386 is incorrect there as it will not pull in i686
kernel packages, so there we need i686, which is why the internal
represenation is stored as x86. And since we sometimes compare the
arches of distros with the arches of repo objects they should be stored
the same way.
Should I understand that x86 is the canonical name for i386? The import code
did transform x86 into i386, so I guessed the latter is the good one. But your
paragraph points that pxegen does the right transformation and that the real bug
was in action_import. If that is the case, let me correct the patch before even
thinking of apply them, as it comes from a misunderstanding.
cobbler distro add --name=foo --arch=x86_64 ... # implies redhat
based
cobbler distro add --name=foo --breed=debian --arch=x86_64 ...
cobbler distro add --name=foo --breed=suse --arch=x86_64 ...
I am also confused by:
+ if os.path.realpath(fullname) == os.path.realpath(dirname):
+ print _("- found self-refering link, probably debian
based distro")
+ self.breed_guess = "debian"
+ continue
This seems to be a kind of strange way to detect that a tree is Debian
based. A better route is probably to have two seperate importer
classes, which I believe someone might have been working on, and require
when importing non-redhat distributions that we specify that is what
they are.
For instance, add a new "--breed" parameter to import.
I didn't want to modify the CLI usage for importing. And I wasn't aware of
the breed argument for distro importing. I also believe that the easier and
the better is to add a breed parameter also to import, so I'll do that.
Just a question, if some inconsistency is found from command line to
real tree (as specify a redhat tree and founding a "debian" symlink),
should I just raise an exception/error or start a user dialog ?
This may take some refactoring of the import code but would be
better
than further complicating it, as already it has to deal with a lot of
variance between different EL and Fedora distributions. Having that
become /more/ complex is really not a good option.
So ideally I think what we want is to see action_import.py become a
switchboard, and then based on the value of --breed given to the import
call, choose the right importer_*.py out of "modules" -- that way we can
arbitrarily support other distributions without having to keep adding
the code to the same importer, which will likely become more complicated
to follow as we add more and more code to it.
I'll take into account the modules approach, but after going deeper into the
code, now I think it is not so much redhat-centric as initially appears. It's
more about the names used than about the underlying logic.
Javier Palacios