Re: Forwarded: RFC: New source packaging format
Jim, it's a clever hack for a morning's work. I don't think it's more than
a mock-up of a real tool to do the job, though. I think we should take the
ideas you've generated and put lots more time and thought into a clean and
elegant design for automated building. I think packaging is just a little
part of that issue.
From: Jim Pick <jim@jimpick.com>
> I don't think that Debian stuff should go upstream.
Do you offer any justification for that? I think it's a really nice feature
when Debian stuff is built into a software package and no diff is necessary.
> You are correct, the stuff doesn't get unpacked automatically.
> I think that's a good thing -- why waste disk space if you aren't
> currently involved in the process of building a package?
In that case, why install the source package at all, instead of waiting
until the moment I need it?
> I have an easy solution for this - make a modified dpkg that understands
> a "pseudo-package" that doesn't really exist - but when you install it
> with dpkg, dpkg will compile it from sources. That way, all we have to
> do is generate "pseudo-package" descriptions for all the binary debs
> we want, and invoke dpkg, and it will do everything in the right order.
> (Well, hopefully - maybe Manoj's pkgorder would help)
> Seems like a pretty quick hack to me, although I am uncomfortable with
> the inards of dpkg.
I would feel a whole lot more comfortable if this was not overloaded on
top of our binary package database. For example, we've just doubled the
number of packages in the package listing. We can hack dselect to not
display them, but why are we hacking dpkg/dselect here? To avoid building
a clean tool to handle the source package task and no other task.
[Dependencies work on source removal too, which is problematical]
> How so? If you don't like the dependencies, just use
> "dpkg --purge --force-depends".
Here we drag dpkg into something it doesn't want to do, because we are
using it for something it wasn't intended for. I'd prefer not to get people
trained to use the --force-depends flag.
>> If I am not mistaken, _all_ source dependencies are actually binary
>> dependencies, because they need the source to be _built_and_installed_.
>
> Not really, the debian source package might require uncompiled source
> or header files from other (upstream) source packages.
Only in the case of circular dependencies between packages should it be
handled that way. Otherwise, the other packages should be built and
installed first. If you are building piece-mal, the packages you depend
on do not need to be built at all, just installed from binary packages.
[Source package overwriting problem]
> This is only a problem in the rare situation where you upgrade a source
> package while in the middle of building a package.
Why? Are you insisting that the user "make clean" before installing the new
package? Or will you rm -r the entire directory from the postrm script?
> I doubt that it is going to be a common problem. Even so, a simple way
> around it would be to declare a dependency for the unpack rule in the
> Makefile to /var/lib/dpkg/info/<packagename>.
This does not take care of removing source files that have been removed
from the archive since the last version, and any generated files.
Thanks
Bruce
--
Can you get your operating system fixed when you need it?
Linux - the supportable operating system. http://www.debian.org/support.html
Bruce Perens K6BP bruce@debian.org NEW PHONE NUMBER: 510-620-3502
Reply to: