[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Forwarded: RFC: New source packaging format



> Please tell me where I am wrong.  

your create complexity where there is none.
source handling works very fine for me, and i simply do not understand
why you add this complexity, like managing sources as root.

i only see the disadvantages.

so : please not show me example code, please show me and explain the
advantages you have with this method. then i can either show you, that
we can get these advantages much easier, or i will step back and say
"hey, there are advantages i did not know, and it's the only way we can
 get them."

currently i'm simply confused.

>  1) How do you propose modifying dpkg-source for handling additions
>     of binary files to Debian packages (without uuencoding them)?

ways that i see :
a) uuencoding them :-)
b) some pkg_ver-1.added.tar.gz handling

>  2) How do you propose modifying dpkg-source so that you can support
>     sharing upstream source between packages (ie. checker)?

i think we need to split and have layers (i don't like big fat programs,
better keep everything small and simple :-)
a) pure handling of source (dpkg-source)
b) source dependency handler, will call dpkg-buildpackage for
	rebuilding, could call debmake/helper to create new package with
	default files, will handle source dependencies. could be merged
	with uupdate machanism (upgrades a source dir to a new upstream
	release).
c) dpkg-source-ftp or dftp-source to grab source files from debian
	mirror. could be merged with watch/uscan mechanism (checks ftp
	server for new upstream release and calls uupdate).

>  3) What if the upstream source comes in multiple files?  How do you
>     propose changing dpkg-source to use pristine-sources for that?

IMO we shall use pristine source for everything, if possible.
i don't think that it is very hard to handle such things. do it once,
and place instructions how to proced in the control file (to be copied
to the .dsc file).

>  4) Can you describe an algorithm for an auto-bootstrap compilation
>     mechanism in detail?

simple recompiling is not hard. i only did not yet rewrite my shell
script (but i promised, and will do).

bootstrap mechanisms are very very hard. lets wait what the freelinux
people archive. we should not create our own mechanism, when there is a
good team working on this, and its likely that many people will use the
result. 

> Please tell me how.  I'm sort of reluctant to scrap my proposal based
> on this assertion.

wyh work as root ? why keep several copies of something ? why building a
box of a box instead of useing the simple box ? your results and
intensions look as good as your examples look strange.

> I am approaching it from the premise that a .deb file is just an 'ar'
> file with two tarballs inside - one for control info and one for
> binaries.  An upstream tarball is a binary.  The Red Hat guys seemed
> to have figured that out.  And why not use the control file?  It
> seems to express the exact same info as a .dsc file.  I though the
> .deb file format was perfectly suited to delivering source.

if i make changes in source with several revisions, it is a very nice
feature, that i only have to transfer diff files. that does not work
with binaries, but with source, and this is why we have a package format
(ar) for binaries, but several files for source.

i think, i understand at least some aspects of what you want to do,
but i don't understand why you do it this way and not a different way.

the discussion between you and ian sounds like two people arguing 
"do it this way !" "no, do it this way !" "no, do it this way !"
without saying what you want to do, and why you want to do it your way.

please write down your arguments, (best : as a sgml document - we will
have the same discussion in 3 months).

andreas



Reply to: