Re: adding different compression types to createrepo

On Wed, Aug 4, 2010 at 13:30, Matthew Dawkins <[email protected]> wrote:
>>
>> Decompress them.
>>
>
> I'm not worried about the decompressed file. Otherwise I wouldn't have
> brought up the subject of better_compression. It's not a decompressed file
> that I want to serve and have downloaded.
>
>> Each user of createrepo - not each user of the repo. And since the users
>> of createrepo don't REALLY matter it seems odd to be targetting them as
>> a 'user'.

We use createrepo, yes, but it's the users of our repos that are
benefited the most.
We have to tailor to their needs.

>
> Well, whatever you want to call them/me/us. As a content provider and a user
> of that same content. I am VERY_AWARE of how to improve it. Each distro
> using createrepo to create a repo for their users, is a user of createrepo.
>
>>
>> the trick is making repos which will work with old and new versions of
>> various pkg mgmt tools.
>>
>
> Like Robert Xu said. Let the distros hash out what format and compression
> they want to provide in their own repos and not let one person or distro
> make that decision for us. If in time your sqlite format is AWESOME, I'm
> sure we will switch, but until that time we will continue to use the xml
> files.
>
>>
>> But it means when I look at the repomd.xml
>> I see the 'primary' datatype and the file is in a format I CANNOT read
>> on an older ver of yum, apt or smart. And if there are no other options
>> available for my pkgmgmt tool in then we have a repo which cannot be
>> read at all.
>
> There would be a simple fix for you. Don't use the xz compression in your
> repo and don't try to add a distro's repo that prolly won't work for you
> anyways. Use the defaults.
>

Isn't that what a repomd.xml file is for?
You can clearly see something is wrong if you download Fedora's apt
package and try to use it.

It'd be nice to have repomd have "backwards compat" in the file.
But then again, why would you use another distro's files?

>
>>
>> So then we get a user who complains that a repo is advertising itself as
>> a particular type of repo but it has unreadable metadata files.
>>
>
> Remember the default would still be gz for xml and bz2 for sqlite.
>
> Also, you seem to forget that a distros repos are very tailored to the setup
> already used by that distro. I'm not trying to offer content to Fedora or
> Opensuse or Xdistro. My pkgs will very well break another distros install.
> And that prolly goes for any other distros as well. The last thing I'm gonna
> do is go add a foreign repo.
>
> Ultimately, I care about my repos. I care about making the download smaller
> for the end user. Xz compression of whatever file format you provide is
> ultimately smaller than gz and or bz2. I'm not trying to provide backwards
> compatibility for older smart versions (the pkg mgr we use) and I'm not
> proposing that someone inadvertently break theirs. It's about a value added
> option, that obviously some repo providers using createrepo would like to
> see.
>
>>
>> that's the merit in having different names for the datatypes, OR
>> as I've suggested elsewhere we have a way of specifying the compression
>> format in the datatype entry as an attribute so we can know if we're
>> going to be compat with a repo just by looking at the repomd.xml and not
>> wasting time/bandwidth downloading the files.
>>
>
> I can understand this, but isn't that what the magic info in a file is
> for??? None the less using what the opensuse patch did seems reasonable no?
> primary_xz
>

Truthfully, I would rather xz the xml files than xz the sqlite files;
The sqlite files would still end up bigger.

-- 
later, Robert Xu