Re: source management within APT
Es geschah am Samstag 14 Mai 2005 14:33 als martin f krafft schrieb:
> also sprach Christian Schoenebeck <schoenebeck@software-engineering.org>
[2005.05.14.1320 +0200]:
> > No, it sounds better like Gentoo. Because APT could automatically
> > manage precompiled binary packages as well as custom (from source)
> > compiled packages seamlessly together with one tool and operation.
>
> I believe Gentoo can do this.
In theory, yes. But Gentoo is simply not designed for handling precompiled
binary packages well. And comparing Debian and Gentoo, I thought it's better
and easier to extend APT for source management than trying to get good binary
support with Gentoo.
> > apt-build looks nice, but I think it's better to integrate source
> > management directly into apt-get, because that way you can use
> > precompiled and custom compiled packages automatically and
> > transparently with one tool.
>
> Unix is the world of small tools in which monolithic swiss army
> knives are frowned upon.
I know. But I'm not sharing the opinion that this is always good. Best, ehm
that is worst example against that "world of small tools" is yacc and lex for
generating parsers. On the first view it makes sense to split them up for the
two tasks tokenizer and semantic analyizer. But in practice this is a very
weak design, because tokenizing is often dependant to the current position in
the grammer tree. In this case the interface between those two apps is simply
too bad designed and due to the nature of Unix to keep behavior and APIs
consistent caused that this is still the case today.
You know I would only do such separation in individual tools if it doesn't
result in constraints in the functionality.
> APT does not install binary packages, that's dpkg.
I know.
> Thus, if you want
> your suggestion to be seriously considered, the best procedure would
> be to provide a dpkg-equivalent for source packages, which does
> exactly what you want in such a way that APT does not have to do
> more than download files and distribute them to handlers, like dpkg
> and your new tool.
Right an individual handler makes sense. But apt-get should be the program for
the user to handle binary and custom compilation installation in one tool. A
separation of binary and source management is bad.
> Don't get me wrong, I like your suggestion. I think it will only
> stand a real chance if you provide some reference implementation
> which does not change APT too much, and which certainly does not
> change the way APT is currently working.
Well, it would add some new commands to apt-get of course and it would change
the behavior if source packages are listed in a certain config file. Would
that mean a harm for your opinion that it shouldn't change APT too much? At
least I don't think so. Because if the user doesn't list any package to be
compiled from source, APT will still behave the same as it always did. Also
consider it's very confusing for new users to have thousands of individual
tools only for package management.
> > Another feature I really would like to see is to have patches
> > automatically generated. Consider you have a build tree with all the
> > sources, you simply edit one of the sources in the build directory and
> > APT will then automatically diff the changes you made and store it as a
> > patch in a patch directory.
>
> Have a look at dpatch and dpatch-edit-patch. It's not automatic the
> way you want it, but that's good since I don't think automation is
> the right thing per default.
I heard of it before. I will look thoroughly if this can be reused for that
approach. And I dont think either automation _by_default_ is good, but
explicit automation is usually good of course.
> > But I do not. CC appreciated. I wasn't even aware this was
> > a public list. Maybe due to the odd name of this list.
>
> Yes, hysterical raisins. No harm done, don't worry.
>
> If you prefer CCs, please consider setting the Mail-Followup-To
> header appropriately. I am not sure KMail can do this automatically,
> though.
KMail can currently only set Reply-To.
> > Btw many source packages from Testing/Sarge do not compile right
> > away. Shouldn't a serious bug report opened against each of those
> > packages?
>
> If they do not compile under the appropriate environment, then yes.
> However, you have to make sure that this isn't your problem. For
> instance, are you sure you have all build dependencies installed?
I made a test run with apt-build and I'm pretty sure it handles build
dependencies automatically. But I will check that of course before reporting
such reports.
CU
Christian
Reply to: