Andreas Jellinhaus wrote: > what about using the orginal upstrem version (the same file, byte by > byte), and having some additional information in the .dsc file (how to > extract the orginal file, from where it was downloaded, orginal md5sum, > rename commands if needed). It would be easier to just use a .deb file (which is really just a "ar" archive, renamed), but call it an .upsdeb or a .sdeb file just so that it isn't confusing. That way, we can re-use the existing plumbing build into dpkg to manage source code the same way it manages binary files. By using an archive, we can add all sorts of additional information in a clean manner. Plus we can have multiple upstream sources in one archive if they logically go together - which makes it much harder to lose things. > this would require a new way of handling dsc file (now thery are > generated), but that shouldn't be too hard. > > the only change is : keep the original filename, or change it ? > (if it is changed, this change should be in the .dsc file). > > commands in a .dsc file would also make it possible, to have N source > files converted to M packages, with everything documented in the .dsc > file (that is usefull for packages of many small programs. one example : > isdnutils constists of ca. 10 commands, put together as one unit > (isdnutils source file was "constructed" by me, because the original > upstream source file wasn't updated, but most individual packages), and > created 2 packages (isdnutils and xisdnutils)). We could modify the .dsc file format - but I feel that the .dsc file format is already way too complicated and you need to write fancy parsers to understand it. If we add more features to it, suddenly the .dsc file starts to look like a new programming language. Why add complexity when it's not needed? > > Of course, this also means we cannot implement a automated system where > > we can check the .orig.tar.gz files in our source distribution against > > the upstream source distributions (located on well known web sites). > > in my way it should work. but creating diffs might be horrible ... Also, sometimes upstream sources have very bad filenames. Oftentimes, the names of the upstream sources might have name collisions with older versions of the same sources (xxx-latest.tar.gz for example). Also, sometimes the upstream sources might come from many different places (ie. look inside the source of the nis package). It would be nice to have the upstream sources "logically" grouped into packages. > > Comments? > > i don't know how good or bad this solution is, but if we make such a big > change, what about : > - implementing source dependencies (this theme was discussed several > times. if we have to change packages anyway...) If we re-use dpkg, we get them for free. > - changing the whole mechanisms to auto compilations. We could have a control file in the .sdeb that would do an auto-compilation, the exact same way the .postinst scripts work for .deb's. Again, I think we get this capability for free if we re-use the dpkg code. > another topic : > it will not help us to have secure debian packages, as long as we use a > source from sunsite mirrors etc. that might be changed. debian > should work together with all other distributions, fsf people and bsd > people to create a common way to make sure, that a packages was not > changed on the way from it's author to debian / linux comunity. it's > one thing to trust a maintainer that his sources are ok, but it's a > different thing to trust a tar.gz that anybody could have created. If we can get PGP-signed checksums for upstream sources, and we can verify the signature against our web of trust - then we've solved the problem. This would have to be optional, of course - but over time we could increase the proportion of code where we can certify where the code came from. Also, if we repackage other packaging systems (ie. Red Hat, FreeBSD, Microsoft ActiveX (with Authenticode), digitally-signed Java), many of these already have authentification systems in place, so we'd benefit from that. Cheers, - Jim
Attachment:
pgpF4AtY3FvQA.pgp
Description: PGP signature