:thumbsup:

What about os.path.join(self.repodir, 'Packages', bnplet, bnp)? It is more close to current repos (at least in Fedora). Or maybe make it configurable?

Hmm, also unexpected structure. What about placing 'normal' packages to 'os', so all subrepos are on same (highest) level?

What about os.path.join(self.repodir, 'Packages', bnplet, bnp)? It is more close to current repos (at least in Fedora). Or maybe make it configurable?

This is the layout dist repos had before. Changing that wasn't on the list, though certainly we could.

Are we talking about a layout like so?

dist-arch
|
|---- Packages
|---- repodata
|---- debug
     |
     |---- Packages
     |---- repodata

Hmm, also unexpected structure. What about placing 'normal' packages to 'os', so all subrepos are on same (highest) level?

Trying not to break existing paths, but maybe that doesn't matter. I'm not sure how many folks are relying on the feature as-is, or how much trouble it would be for them to change their urls.

'os' might not make sense for all tags, though.

Current PR creates following:

tag/repo_id
├── src
│   ├── a
│   ├── repodata
│   └── z
└── x86_64
    ├── a
    ├── debug
    │   └── repodata
    ├── repodata
    └── z

I've suggested:

tag/repo_id
├── src
│   ├── Packages
│   │   ├── a
│   │   └── z
│   └── repodata
└── x86_64
    ├── debug
    │   ├── Packages       
    │   │   ├── a
    │   │   └── z
    │   └── repodata
    └── os
        ├── Packages       
        │   ├── a
        │   └── z
        └── repodata

But yes, it is not compatible with current layout. On the other hand, I find it little messy to have all these data mixed in one level (especially letter-based dirs with its repodata and debug directory).

About 'os' - do you mean just the name doesn't make sense, or even location when everything is put together (default behaviour)?

@tkopecek I actually prefer your suggested layout, but the name os is definitely wrong. Maybe make that name configurable, so that it can be release, updates, testing, etc.?

The reason I like your layout is that it makes it easy to merge tag exports together easily on the filesystem.

That said, the current layout proposed probably makes sense too, and is less difficult for naming. And the tag/repo-id already exports out as a top level directory...

About 'os' - do you mean just the name doesn't make sense, or even location when everything is put together (default behaviour)?

I mean the name. The content of a tag might not constitute an os. It could just be a small set of packages.

So, we're inflating the feature quite a lot here....

It'd probably be easier to go without the os directory. The current proposed layout works, though I like the idea of the [a-z] directory being under a Packages directory.

Yep, I think we can just store rpms in Packages dirs, so there is a little cleanup and no change to current repomd path.

Ok, that much is easy enough and not a compat problem

Will update PR shortly

@mikem: Would it also be possible to consider lib{,x32,64}* as a separate prefix to l? This would be similar to what Debian/Ubuntu does.

For example: http://archive.ubuntu.com/ubuntu/pool/main/

Oh, because of dir size? Interesting, but I don't know if we need to rush that in right now.

@mikem Yes. This gets really painful in Mageia because we do lib packages for every library, so the enumeration of the l directory is obnoxious.

For repos, traversing the directory should rarely be done. The whole point of a repo is to use the repodata as an index.

@mikem It's mainly for partial syncs and a few other things done by people in our community...

In Fedora, l is one of the bad ones, but not nearly as bad as p.

$ cat rpms | cut -c 1|sort|uniq -c|sort -n|tail
   2128 a
   2427 c
   3007 s
   3021 n
   3039 r
   3646 m
   6316 l
   6458 g
   7576 t
  13858 p

So, I'm open to making an adjustment here, but probably not for 1.16, which we are currently trying to freeze for.

that's f28 x86_64 data btw. Looks like p accounts for almost 20% of rpm names there. l is only 8.9%. For reference 1/26 is about 3.8%.

For current Mageia Cauldron, this is what it looks like:

$ cat cauldron-rpms | cut -c 1|sort|uniq -c|sort -n|tail
    715 o
    833 j
    899 n
    954 a
   1008 r
   1356 s
   1452 g
   1500 m
   6859 l
   7340 p

p is a bit higher than l, but they're both up there...

This probably needs to be either 1) a configurable regex, or 2) dynamically split based on the content in the repo. Either way, I don't think we need to hold up 1.16 over it. Do you?

Maybe you could file this is a separate rfe?

@mikem No, I don't think it needs to be held up, but I wanted to give that initial feedback for consideration.

@mikem For what it's worth, a configurable regex makes sense, because we may want to also split on perl- and python[23]- prefixes, too...

@mikem, I've filed the request as #915.

Commit 18600b24 fixes this pull-request