On the need for a unofficial .deb archive
I've read the threads that followed after DWN's mention of
the plans to restart the DFMR (Deb Freshmeat Repository).
Some questions have been raised, and some comments made, and I have a few
answers and comments back. All of this is my own opinions, and I speak
for no-one but myself. I have no connection with Freshmeat itself, and no
official position with DFMR as of yet.
A new archive?:
First all, DFMR existed in the past. This is not a new archive being
created as a knee jerk reaction (as someone said). DFMR was always
unofficial. Freshmeat has a deb link line available for all software
listed on it, but in many cases, when a deb link does exist, it's either a
dead link to the old DFMR or not very useful (no links to current Official
Debian packages for instance).
Does this benefit Debian users?:
One goal is to make Freshmeat (and appindex, a currently packaged program
that uses the Freshmeat applist) more useful to Debian users, even those
who maintain strictly 'official' systems, with no non-official packages.
Secondly, Freshmeat is already a well maintained and highly visible
application list and doing this will encourage more .debs to be made for
new and existing software. The plan is that deb that are well suited to
becoming official will become official. It would be an honor to
'graduate' something into Debian proper. This is not meant to replace but
to supplement. Packages which are already in Debian would remain in
Debian, and the DFMR would be for as yet unofficial packages... One good
example would be XF864.0. Branden had good reasons to hold back on
packaging 4.0, yet unofficial debs appeared. Having a good location, with
bugtracking, etc would have been great for those who wanted/needed to run
4.0, without Debian itself having to 'support' it.
debian-freshmeat@lists.debian.org:
The mailing list for debian-freshmeat is a debian.org hosted mailing list,
but it has been inactive for some time. For some reason, it's not being
archived. I subscribed to it recently and posted a 'Anyone alive?'
message and was told the list had been silent for a very long time. Upon
reawakening, Patrick Lenz of Freshmeat kindly offered to restart the DFMR
if others would help to make it useful. We need someone(s) to manage the
archive. Experienced maintainers would be the ideal candidates.
BTS, reportbugs:
Patrick has installed debbugs already - the same bugtracking software that
Debian uses. reportbugs currently accepts gnome, Mandrake Linux, KDE, and
TDYC as valid BTS systems. Adding DFMR would allow bug tracking to occur
as easily as it does with official packages. This coupled with the
existing Freshmeat comments section should allow the quality of a package
to be quickly assessed and hopefully fixed.
Security, responsiblity and gpg:
Signatures and other options have been discussed and mostly await some
decisions being made by whoever ends up 'in charge'. My submitting news to
DWN was one method of attracting some help and attention and hopefully a
few interested archive maintainers. If you are interested, please join
the DFMR mailing list and let us know.
Quality, lintian, conflicts:
It's my hope that whoever takes the job will maintain quality by insisting
on packages that pass lintian checks, have no namespace/version/provides
conflicts with 'official' packages, and that if a package isn't secure or
bugfixed in a reasonable time, they'll do something about it.
Why unofficial?:
Debian, by very nature and structure will never be able to include
everything. In fact, already the KDE/QPL licensing issue and the
non-free issue are causing serious discussion in many circles. Regardless
of your position on either of these, I think everyone might agree that
having an aptable source for these packages is one answer. I have seen
many of the opponents of including KDE saying things like "Well,
if you want it, just add a line to your sources.list" and the same for
opponents of non-free.
Non-Debian:
Corel and Stormix are just 2 of the deb using distributions which are
_not_ Debian official... I expect many more to appear. deb packaging is
just much nicer than rpm. Having an unofficial archive means that things
that don't fit Debian itself can still be made avaiable to all. Opera,
Corel Photopaint, and other 'free' downloads with restrictive licenses
might agree to allow DFMR to mirror these debs in an aptable format.
KDE/QPL:
If Freshmeat is willing to host KDE apps, fine. This is not why the DFMR
is being recreated, but users might benefit regardless.
non-free:
Regardless of Debian's decision to keep non-free or not, there will always
be packages that Debian doesn't want to package, can't package, or
shouldn't package for whatever reasons. I believe strongly in Free
Software, but non-free software exists, and having a single central
aptable source would be useful, especially if quality is a priority.
Aptable and non-aptable:
Unofficial apt sites already exist... what DFMR is meant to do is create a
more central location, with some order in the chaos. Stephane Bortzmeyer
has done a great job with the unofficial apt list, tracking the multitude
of sites out there. Helixcode and tdyc are 2 sites that are good aptable
sites. I'd like to see the smaller aptable and all of the non-aptable
sites converge on something centralized like DFMR.
Many highly regarded Debian developers have a public aptable site for
cutting edge releases, so questioning the packaging quality of the debs
there isn't very logical... Yes, they might be bleeding edge, but not
poorly built.
Some Authors might make a .deb available, but not be a part of Debian, and
they don't make an aptable site because it's too much work, or they don't
know how. So they put the deb out there, and then users have to download,
and check back regularly for updates. DFMR would allow an author to
submit a deb and have a good infrastructure without forcing the author to
become a developer or find a sponsor. Getting the package into Debian
proper might be in the works, but the software is out there in the
meantime this way.
New Maintainers:
I'm in the queue to become a maintainer. So are many others. I look
forward to the process, and to creating new official packages. However,
up till now it's been a very slow process (years for some people), and
even now, the process is involved, strict, and controlled. There will be
those who want to package things that Debian doesn't plan to include,
those who don't want to sign the Social Contract, etc.. Excluding these
people and packages isn't the answer, I feel. Creating a central
unofficial place is an answer. Joe Foobar decides that he want to package
propietary-foo, because he uses Corel... this would give him a place to
put it with minimum hassle and maximum exposure.
'debfind.net', rpmfind.net etc:
rpmfind.net isn't perfect because of the nature of RPMS and different
distros, NOT because of the archive itself. Deb packaging tends to work
on all distributions that use it, if it's built right, Mandrake Cooker has
a great contrib archive... often people have rpmed the most current
version for Cooker long before anyone else has packaged it.
ITP & RFS, ITO, sponsors:
The whole ITP process only works, as a few pointed out, if the ITPer has
the right/privilege to put the packaging into circulation. That limits it
to developers only. This, to me, strikes me as not being very 'Open
Source' or 'free software' oriented. I thought the point was 'release
early, release often'. DFMR would allow fledgling developer-wannabes
(possibily the author of the software him/herself) to package first and
then get official after. Errors would be found quickly, and they wouldn't
be in unstable, they'd be in a buffer zone, not affecting Debian at
all. Debian could skim through the crop, picking up the better packages
and developers and making them official. Sponsorship would be easier,
since the packages would be out there for all to see. Orphaning would
happen, of course, but hopefully a decent package would find a new owner
a little quicker, since it'd have more eyeballs on it.
I invite anyone interested to continue the discussion on
debian-freshmeat...
Seth
Reply to: