Re: Finding a source package
Joey Hess <[EMAIL PROTECTED]> writes: > Guy Maor wrote: > > I'm suggesting that dpkg-scanpackages scan the dscs and put the > > section and version in the Source field, or perhaps add a new field > > Dsc which is simply the full path to the dsc, akin to the Filename > > field. Then downloading the source for a package is simple. The web > > pages would use this field too. > > But .dsc's are pgp signed by thier creators. How would you edit them? I'm speaking of the fields in the Packages line. By fixing those, I get the correct info into dpkg/apt's database. It can then find the dsc. From that it can find the rest. Guy
Re: Finding a source package
Guy Maor wrote: > I'm suggesting that dpkg-scanpackages scan the dscs and put the > section and version in the Source field, or perhaps add a new field > Dsc which is simply the full path to the dsc, akin to the Filename > field. Then downloading the source for a package is simple. The web > pages would use this field too. But .dsc's are pgp signed by thier creators. How would you edit them? -- see shy jo
Re: Finding a source package
<[EMAIL PROTECTED]>(James A. Treacy) writes: > Guy Maor wrote: > First, due to NMU uploads to other architectures, the source version > may not match the version: in the package you are looking for. > This means you need to search the archive for the name of the .dsc > file. There are about 75 version mismatches in slink (only 2 in hamm) > so this is not a minor issue. It actually is a big problem considering the GPL. Debian could be asked for any source, for wich a binary is awaylable. That means, to be on the save side, eigther old sources must be kept as long as there are binaries of it, or binaries must be deleted when a newer source is uploaded. The second of which is not aceptable at all. Also all sources the package source depends on (like libs, tools, ...) must be present in the version used to build a package, otherwise the might not be rebuild from its source. Having no source dependencies and no version tracking for binaries, this is actually impossible to guranty without keeping all old versions but source dependencies would help a lot in assuring that sources are awailable as needed by the gpl. Together with the source dependencies the upload scripts must be changed to delete source no earlier then when the last package that depends on it is removed (or updated to a newer version). May the Source be with you. Mrvn
Re: Finding a source package
[ Please don't Cc me on replies to a public mailing list ] <[EMAIL PROTECTED]> (James A. Treacy) writes: > > <[EMAIL PROTECTED]>(James A. Treacy) writes: > > > > > Should apt have to download the dsc file for a package before it > > > knows what the source files are? > > > > Why on earth not? If it's going to download the source, the .dsc file > > is part of the source and has to be downloaded anyway. > > It is clearly much more efficient if the .dsc files don't have to be > retrieved. Eh? Have you ever used dpkg-source? The .dsc files _have_ to be retrieved because they're an essential part of the source package. (In any event .dsc files are usually no more than several hundred bytes; hardly worth making a polava over) > > Then they have 2 options: [...] > These are both hacks (in the bad sense of the word. Kluge is a better (Kludge even) > word, but many people won't know it). No; (1) is a kludge, (2) is a perfectly valid solution and poses no real problems that I can see, as opposed to allowing multiple source versions of the same package which poses lots of problems for little or no gain. [And I'm speaking as a porter; multiple source versions of the same source and with the same name would give me the mother of all headaches.] -- James
Re: Finding a source package
<[EMAIL PROTECTED]>(James A. Treacy) writes: > It is clearly much more efficient if the .dsc files don't have to be > retrieved. This is simply a matter of policy though. I guess you're talking about different things. Of course that package's dsc needs to be downloaded, but Jay fears that all the dsc would have to be downloaded, perhaps as an index. I'm suggesting that dpkg-scanpackages scan the dscs and put the section and version in the Source field, or perhaps add a new field Dsc which is simply the full path to the dsc, akin to the Filename field. Then downloading the source for a package is simple. The web pages would use this field too. > I see no reason not to simply allow multiple versions of source into > the archive. It's not so much multiple versions of source in the archive that I object to. It's multiple versions of source. The same source package should build on all platforms. Guy
Re: Finding a source package
> <[EMAIL PROTECTED]>(James A. Treacy) writes:
>
> > Should apt have to download the dsc file for a package before it
> > knows what the source files are?
>
> Why on earth not? If it's going to download the source, the .dsc file
> is part of the source and has to be downloaded anyway.
>
It is clearly much more efficient if the .dsc files don't have to be retrieved.
This is simply a matter of policy though.
> > Suppose one port needs a wildly different version of a program
> > to have it work on that architecture.
>
> Then they have 2 options:
>
> (1) Do dirty disgusting hacks like I did for binutils on m68k. (Do a
> binary upload of the different version, ignore the source from
> then on [\begin{plug}trivially with quinn diff\end{plug}])[1]
>
> (2) Upload a new source package with a different name, e.g. foo2.1 as
> opposed to foo or whatever. (Already done for, e.g. glibc)
>
These are both hacks (in the bad sense of the word. Kluge is a better
word, but many people won't know it). I see no reason not to simply allow
multiple versions of source into the archive.
Jay Treacy
Re: Finding a source package
<[EMAIL PROTECTED]>(James A. Treacy) writes:
> Should apt have to download the dsc file for a package before it
> knows what the source files are?
Why on earth not? If it's going to download the source, the .dsc file
is part of the source and has to be downloaded anyway.
> > > If there are plans to allow multiple source versions into the archive
> > > simultaneously then this will need to be rethought.
> >
> > No such plans.
>
> This is not good.
I disagree.
> Suppose one port needs a wildly different version of a program
> to have it work on that architecture.
Then they have 2 options:
(1) Do dirty disgusting hacks like I did for binutils on m68k. (Do a
binary upload of the different version, ignore the source from
then on [\begin{plug}trivially with quinn diff\end{plug}])[1]
(2) Upload a new source package with a different name, e.g. foo2.1 as
opposed to foo or whatever. (Already done for, e.g. glibc)
--
James
[1] Yes, this is horrible and I should do something better.
Re: Finding a source package
Guy Maor wrote: > <[EMAIL PROTECTED]> (James A. Treacy) writes: > > > First, due to NMU uploads to other architectures, the source version > > may not match the version: in the package you are looking for. > > This could be corrected with dpkg-scanpackages, but that's not really > the right thing to do. I don't know the best way to handle this. > > > Second, even if you find the name of the .dsc file you need to look > > in every one to find the names of the source files. > > Huh? If you can find the dsc, then the other source files will be > right along with it. > You are assuming that a copy of the archive is sitting on the local machine. For generating Debian web pages that isn't a problem, but if apt wants to add the downloading of source files then this becomes a problem. Should apt have to download the dsc file for a package before it knows what the source files are? > I'll look into having dpkg-scanpackages scan the dsc's as well and add > sections at least. AFAIK, no programs parses them yet? I'd rather > not have a new index file. > I also would rather not have a new index file, but Jason and I have not come up with an alternative. Even though it is possible to find the information needed to generate (working) source downloading for the Packages web pages, it would be much more efficient if every dsc file didn't need to be scanned in the process. > > If there are plans to allow multiple source versions into the archive > > simultaneously then this will need to be rethought. > > No such plans. > This is not good. Suppose one port needs a wildly different version of a program to have it work on that architecture. Only the source to one of the versions will be available. I admit this isn't common. It is common, though, for the versions on different architectures to be off. If we could guarantee that it was always the latest version of source left in the archive it wouldn't be so bad. What happens though is an old version of a package is uploaded for one port after a newer version has been released for a different port - overwriting the new version. This needs to be fixed. Jay Treacy
Re: Finding a source package
<[EMAIL PROTECTED]> (James A. Treacy) writes: > First, due to NMU uploads to other architectures, the source version > may not match the version: in the package you are looking for. This could be corrected with dpkg-scanpackages, but that's not really the right thing to do. I don't know the best way to handle this. > Second, even if you find the name of the .dsc file you need to look > in every one to find the names of the source files. Huh? If you can find the dsc, then the other source files will be right along with it. I'll look into having dpkg-scanpackages scan the dsc's as well and add sections at least. AFAIK, no programs parses them yet? I'd rather not have a new index file. > If there are plans to allow multiple source versions into the archive > simultaneously then this will need to be rethought. No such plans. Guy
