Re: [APT2] Initial public push
On Mi, 2010-08-11 at 17:51 +0200, David Kalnischkies wrote:
> Hi Julian,
>
> 2010/8/11 Julian Andres Klode <jak@debian.org>:
> > Today, I am opening the source code for APT2. APT2 is a LGPL-2.1+
> > licensed, multi-distribution[1], package management solution consisting
> > of a library (apt-2.0) and a command-line frontend (capt); both
> > implemented in C.
>
> Good luck & success with your project!
>
> But…
>
> > You should not confuse this APT2 with the previous attempt last year.
>
> Please do yourself and everybody else a big favor: Rename it.
>
> APT2 sounds more like a fullfeatured and fullworking dropin replacement
> for the long known APT than a complete (and currently incomplete)
> rewrite which handles some stuff differently -- even if it is only a different
> library requirement through i guess its more (planned)…
I guess the differences between GRUB and GRUB 2 are more dramatic. And
APT2 shall become what it sounds like. And I can imagine that at least
the Python bindings will get a complete compatibility layer.
>
> I wouldn't publish my new shiny (and much better) desktop environment
> with the name GNOME4, KDE5, XFCE2 or LXDE1½ for the same reason
> even if it would behave nearly the same way as one of those…
Well, you're the only one to complain about the naming.
>
> > The capt tool is the command-line front-end to the library. It is an
> > all-in-one tool similar to capt.
>
> Same story, even you confused cupt and capt in this sentence…
Yes, I know. But having a consistent naming scheme (capt (command-line),
gapt (GTK+), kapt (KDE), napt (ncurses)) makes sense to me. But if this
gets too confusing, I could rename it to apt2 (although I prefer capt).
>
>
> I would personally be more happy to see more people working on the
> original than on his nearly uncountable reimplementations and forks,
> but we are talking about free software so i can't nor i want to force anyone.
> (and i am talking not only about APT with this sentence…)
Despite working on APT2, I continue to work on APT and python-apt. Other
projects benefit from the work I do on APT2, because I check other
implementations and report bugs (ask Eugene) and backport features (as
could be seen in the regex/globbing support in APT).
Reference:
http://bugs.debian.org/cgi-bin/pkgreport.cgi?archive=both;src=cupt;submitter=jak%40debian.org
>
> C + glib and C++0x (cupt rewrite) aren't as far away from C++ as vala and perl
> were so maybe the projects can benefit at least a bit from each others code.
License overview:
* apt: GPL-2+
* apt2: LGPL-2.1+
* cupt: GPL-3+
Regular expressions: cupt and APT2 [1]
Binary cache: APT and APT2
Dependencies: cupt has an insane amount of them
Accessor functions: APT:no, APT2:yes (completely opaque), Cupt:no
Designed as library: APT:yes, APT2:yes, Cupt:no
Designed for multiple distributions: APT:alongtimeago, APT2:yes, Cupt:no
>
>
>
> Best regards,
>
> David Kalnischkies
>
>
> P.S.: The Build-Depends doesn't indicate that you need
> to have libapt-pkg-dev installed to build it from source
> (for whatever reason it is needed, it at least complains about it
> and the resulting capt is linked against it).
Well, it currently imports APT's cache until the cache generation stuff
is done (which needs abstraction first). And capt has a 'vertest'
command which compares APT2's version comparison against APT's (which
will move somewhere else or will be removed)
[1] cupt uses regular expressions a lot more; Eugene, could you
re-license your regular expressions as LGPL-2.1+, so we can share them
where appropriate?
--
Julian Andres Klode - Debian Developer, Ubuntu Member
See http://wiki.debian.org/JulianAndresKlode and http://jak-linux.org/.
Reply to: