debfind.net (was: GNOME-HELIX)
Hurry up to register debfind.net! We're on the bleeding edge now!
Hehe.. Read on please. 8)
Paul J Thompson wrote£º
>> > 3) If I install them and build the package which depends on the
>> > helix-gnome-core, the package must depends on the gnome-helix.
>> > Can I build the package which depends on the helix-gnome, and
>> > upload it as a Debian package?
>>
>> No, packages in Debian mustn't be compiled or depend on packages that
>> aren't in Debian.
>
>I am not suggesting we change this rule. However, something needs to be
>done considering this situation.
>
>Gnome-helix is the best set of gnome packages available for Debian and
>it would be a step backward for ANY Debian developer to build their
>gnome packages against anything else.
>
>Unfortunately, the current system does not allow official Debian
>packages to depend on non-Debian packages. So, what do we do?
>
>I would suggest that we try to find some way to integrate the
>gnome-helix Debian packages into the official Debian distributions.
>Maybe we could ask one of the gnome-helix people to sign on as an
>official Debian developers or something like that?
1) Just curious that is it a good thing to do to have a Helix
employee joined Debian as an individual instead of as an entity
to represent his/her company while this person's intention to
work with Debian may probably end when s/he is not on the
position on his current packaging job? (Become a manager,
move company, etc.)
Shall Debian consider to accept special entity from a
commercial company which complies to DFSG on their
Debian related work? Shall there's be something as a
Debian consotium? What does the consitution say?
2) Things are changing that DEB as a packaging format is
just going beyond the Debian distribution, just like the
RPM packaging format has been long going beyond the Red
Hat distribution.
And as a matter of fact, since DEB packaging format and
related facilities are free software. Everybody, including
well-financed companies, whether a good citizen in the FS
community or not, could use the technology. And they ARE
using it NOW.
Shall Debian the project works a resolution to help prevent
the DEBFIND.NET-like things?
The recent Kudos-mail for an upgrading from a libc5 Debian
to the newest one shed somelight that DEB tech could well
survive the mess maybe. I mean users could shift from one
whole bunch of one-line-sources.list of packages to just
another holy bunch of one-line-sources.list of packages
probably. But is this the desired thing todo? Dunno.
And can really DEB tech do that if the just holy bunch
of one-line-sources.list of packages are not well packaged?
I guess this would be the most interested thing to work
on and to test and to see. I guess this would be the critical
difference between a DEBFIND.NET and the RPMFIND.NET, eh?
Geez, dpkg/apt or some will REJECT to install that DEB
on the system??? because it's not well packaged to follow
the Debian(-Consortium) policy???
Will the above be a typical discuss in the future
Debian-Devel? 8)
--
zw@zhaoway.com
http://www.zhaoway.com/
___________________________________________________________________
·îÏ×°®ÐÄ£¬¹²½¨ÍøÒ×£¨http://www.163.com£©¼ÒÔ°£¬ÇëͶÎÒÃÇһƱ¡£;
http://fsurvey.cnnic.net.cn/survey/index.html
Reply to: