[repo-coord] Repo information inside rpm?

[Dag Wieers]

On Fri, 13 Aug 2004, Morten Kjeldgaard wrote:

> > + Why would you put the language in there ?
> 
> Because some repos, like for example ATrpms, have a language component in the
> path:
> 
> rpm http://apt.physik.fu-berlin.de/ fedora/1/en/i386 at-stable

Ok, for that purpose I understand it, although I don't understand your 
goal to have a unique URL for each package.


> > + Why would you put the architecture in there ? It's already part of the
> >   package.
> 
> Yes, but the apt convention is to put both i386, noarch etc. RPMs into the
> same directory called "i386". You yourself have "i386" and "x86_64"
> directories in your repo. So "arch" has to do with the repo organization, not
> the RPM itself.

Well, my noarch and i386 packages in i386 and x86_64 are the same and I'm 
not considering to make extra packages for this purpose.

 
> >   seperate repository, it would mean you can't move it later without
> >   rebuilding ?
> 
> Right. Not if you want to keep things consistent. On the other hand, how often
> do you move a package from one component to another?? Perhaps from "unstable"
> to "testing" and later to "stable", but then it probably requires rebuilding
> anyway.

No, once a package becomes ready for testing I specifically not want to 
rebuild it, same for stable. I may consider changing the headers of the 
RPM package, but JBJ doesn't want to create such a tool. Still, I'd think 
that would be very useful, even for the purpose you state.

 
> > Well, I think some of the values would be useful to have, but I don't
> > think you're doing it for the right reasons. If the goal is to extract an
> > Apt/Yum location, I don't think that is a good idea. What about i568
> > packages that are part of the i386 repository or even x86_64 ? What about
> > noarch packages ?
> 
> Not a problem, as explained above. I can tell you are confused ;-)

I often am, but not right now :)


> > Why do you want to extract an Apt location ?
> 
> That's a very good question! Well, first of all, I want to use it when I build
> packages. When building, my packages end up in the place defined by %_rpmdir
> and %_srcrpmdir. I am really tired of moving the packages by hand to my apt
> directory. I keep making mistakes. If the package contains the apt location, I
> can write a script to move it over.

I'm placing them in a directory called packages based on the name. And 
based on the filename (dist and arch) I later hardlink them to the right 
repository just before generating the repositories and syncing with a 
mirror. I think that's a better approach and I have no problems with doing 
things manually. Based on the filename I have enough information (at least 
for myself) to place it correctly. Once you talk about 
stable/testing/unstable I agree with you that it will not work, however I 
wouldn't want that piece of information inside the package, unless I could 
change the header without rebuilding.

 
> Secondly, say you find a neat package somewhere, and say "I'd like more stuff
> from this repo". Well, you can extract the apt location and see what is there.

Or you can search for the filename on google or rpm.pbone.net, I don't 
think people are actually interested in this.


> Thirdly, having the repo information there <em> will tell you where to go to
> resolve dependencies </em>. This could be extremely useful in the future as
> apt/yum tools become smarter and smarter.

Well, a google would help with that too. The packager-information (or 
website) would help too. If people don't know about rpm -qi (or don't know 
about google) why would they know about the tool you think they're going 
to need ?

Once again, I don't object to the idea, but I don't think that it is 
useful for that purpose. However an extensible header inside a package 
could be useful for some purposes, one is Axel's idea of having packages 
belong to multiple 'categories' or package-sets.

But it obviously would require client-support too. (the new yum and apt 
allow something like that from another perspective so generating the 
correct comps.xml fro mthe SPEC-file or RPM files would be useful too).

--   dag wieers,  dag at wieers.com,  http://dag.wieers.com/   --
[Any errors in spelling, tact or fact are transmission errors]