lated machinery.
What needs to be done:
- package a new upstream release;
- solve a (documentation-related) FTBFS;
- potentially make a shared library instead of a static library.
Regards,
--
Eugene V. Lyubimkin
C++ GNU/Linux userspace developer, Debian Developer
Hi Kristian,
To one of your side questions,
On 24.10.2016 02:33, Kristian Erik Hermansen wrote:
>> 1) Checking chain (e.g. gpgv and its callers) have bugs. True, same as
>> checking layer for secure transports also have bugs.
>
> Agreed. Please let me know of a good test case to validate that y
Hi Russ, Kristian,
On 24.10.2016 07:19, Kristian Erik Hermansen wrote:
> On Sun, Oct 23, 2016 at 7:28 PM, Russ Allbery wrote:
>> The idea is to *add* HTTPS protection on top of the protections we already
>> have. You're correct that it doesn't give you authentication of the
>> packages without a
Hi,
[ please don't CC me directly ]
On 23.10.2016 17:20, Kristian Erik Hermansen wrote:
> On Sun, Oct 23, 2016 at 7:23 AM, Eugene V. Lyubimkin
> wrote:
>> I'm a developer of a tool which downloads and validates Debian archives
>> in a similar way APT doe
Hello Kristian,
On 23.10.2016 15:04, Kristian Erik Hermansen wrote:
> [...]
> Although APT theoretically protects tampering of packages in transit
> over HTTP based on the signing key, there are numerous ways to exploit
> the plaintext HTTP protocol in transit and the way APT handles some
> aspect
If as the project we agree that we
cannot uphold those standards anymore, we should either:
a) move such software out from 'main' (to 'contrib' or whatever else
applicable);
or
b) openly and officially relax our standards, stating that an ability to build
modified so
Package: wnpp
Severity: wishlist
Owner: "Eugene V. Lyubimkin"
* Package name: cppformat
Version : 1.1.0
Upstream Author : Victor Zverovich
* URL : http://cppformat.github.io/
* License : BSD 2-clause
Programming Lang: C++
Description : fast
how to proceed?
[1] mainly python-related + libidl0, > 800 binary packages in total
--
Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com
C++ GNU/Linux userspace developer, Debian Developer
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of
> dependent on score).
Unless this is documented in Debian Policy, please don't depend on this
specific behavior [1] and make a transitional dependency, AFAIK this is
how it was done for several transitions of Essential packages in the
past.
[1] there are other package managers, plus aut
ax would be just as good.
--
Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com
C++ GNU/Linux userspace developer, Debian Developer
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas
Hi,
Thank you for comments.
2013-05-09 18:44, David Kalnischkies:
> On Wed, May 8, 2013 at 8:51 PM, Eugene V. Lyubimkin wrote:
> > Soft-Depends: a {90%}, b (>= 1.2) {20%}, c (>= 4) {99%}, c (>= 6) {70%}
>
> If we assume its already hard to decide "recommend
; and
'Recommends: y' -- 'Soft-Depends: y {90%}'.
Numbers/tags are quite arbitrary -- to give the picture.
--
Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com
C++ GNU/Linux userspace developer, Debian Developer
--
To UNSUBSCRIBE, email to debian-dev
sucks, proposals welcome)
Doesn't require any middle steps.
--
Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com
C++ GNU/Linux userspace developer, Debian Developer
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe&qu
- often porting bugfixes from already released upstream point releases
-- zero benefit to upstream/non-Debian users, less tested changes.
[4] if there is no viable alternatives
[5] as opposed to freely working on unstable
[6] but quite broad
--
Eugene V. Lyubimkin aka JackY
statements are not based on something I wrote myself. TIA.
--
Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com
C++ GNU/Linux userspace developer, Debian Developer
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Tr
n, stopping developing the standards. Have seen examples of all
that occasionally.
I believe this hurts Debian (or any other project which chose to
not accept choices in certain areas) in the long run and don't fit to
'making [...] technically excellent' well.
YMMV.
--
Eugene V.
..]
I wrote a small program to list them, please find the (hopefully
awk'able and hopefully correct) output in attachment.
--
Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com
C++ GNU/Linux developer, Debian Developer
avahi-ui-utils: Recommends: 'vnc-viewer' [c
On 2012-07-11 14:33, Gergely Nagy wrote:
> "Eugene V. Lyubimkin" writes:
>
> > Moreover, despite me understanding the picture, I still
> > has no clean, safe and documented way to do what I'd want in case the
> > package maintainer chosed Depends.
>
On 2012-07-10 22:21, Andrei POPESCU wrote:
> On Ma, 10 iul 12, 22:07:10, Eugene V. Lyubimkin wrote:
> >
> > ... And I disagree with that. No solution can override policy's "all
> > Depends must be satisfied". If one choose to support the "exclude from
>
On 2012-07-10 20:15, Jonas Smedegaard wrote:
> On 12-07-10 at 07:35pm, Eugene V. Lyubimkin wrote:
> > On 2012-07-10 18:10, Jonas Smedegaard wrote:
> > > The very purpose of a meta-package is to _ensure_ that a certain set
> > > of packages is installed, not just re
singlepackage', why $packagemanager now wants
to remove all $metapackage?"
, so I know I'm not alone. Using Recommends for non-core parts of
metapackages' dependencies would nicely solve that.
--
Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com
C++ GNU/Linux
ported by most if not all high-level packages managers in
Debian. Therefore it's totally appropriate for the task.
--
Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com
C++ GNU/Linux developer, Debian Developer
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian
es wrong should be fixed instead.
--
Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com
C++ GNU/Linux developer, Debian Developer
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.deb
On 2012-06-19 14:01, Ben Hutchings wrote:
> On Tue, 2012-06-19 at 15:29 +0300, Eugene V. Lyubimkin wrote:
> > Hello,
> >
> > On 2012-06-19 13:59, Tomas Pospisek wrote:
> > > This implies that an "apt-get install library" needs to trigger that
> > >
yer for proposed functionality -- apt-get
(libapt) is not the only high-level package manager for Debian.
If I were you, I'd look into dpkg file triggers instead. Triggers will
by the way automatically solve the problem that you don't restart
a service 5 times if 5 libraries were u
pt, one of the
> core Debian tools. Apt in turn relies on open standards like HTTP and
> FTP to interoperate with the rest of the world.
As someone who had to reverse-engineer APT repository format I fully
agree with the above. With one minor addition that some software which
is (non-core
[ sorry for duplicate, Neil, pressed the wrong button ]
On 2012-03-26 09:17, Neil Williams wrote:
> On Mon, 26 Mar 2012 09:55:35 +0300
> "Eugene V. Lyubimkin" wrote:
[...]
> > No, it's not nothing, and it's not a pointless bureaucracy. Filing an
> >
> certianly to ignore old "intent" and get on with it.
Absolutely disagree. Hijacking the ITP and/or package name without
saying a single word about that to the ITP bug thread is just plain
rude.
--
Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com
C++/Perl
ey are. i18n/Index is referenced from Release.
--
Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com
C++/Perl developer, Debian Developer
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@li
the cleaner testing.
P.P.S. Thanks for care.
--
Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com
C++/Perl developer, Debian Developer
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@
On 2011-09-04 15:42, Vincent Danjean wrote:
> On 04/09/2011 14:44, Eugene V. Lyubimkin wrote:
> > While I also would want Debian to eventually get rid of circular
> > dependencies, I am not sure about (the value of) the benefits.
> >
> > For example, even by default d
ll have to wait at least
2 stable releases until they could drop the relevant parts of the code.
Therefore I think _for this moment_ mandating in the policy will be too
strict.
--
Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com
C++/Perl developer, Debian Developer
--
To UNS
'use' flag (i.e. by default), all 'optional' packages are
built. And like in the original proposal, there's a header in the
resulting .changes (and possibly in something else) which determines what
was the value of the 'use' flag when building, like
Built-With:
27;s a regular user access, not root one, given I
pre-checked package maintainer scripts before the installation.
'Recommended-When' gives them (= packages from any repositories) an
ability to be installed by default accompanying any package they want. A
major difference as for me.
--
Euge
pot further statements about this in the end of your mail.
So, no, this subthread is not about reverse recommendations, it's about
conditional recommendations. I don't need to rescan the whole repository
to satisfy '!A | B-plugin-A' given I scanned it once for Provides.
--
Euge
> http://lists.debian.org/debian-devel-announce/2011/05/msg7.html
> http://lists.debian.org/debian-devel-announce/2011/05/msg8.html
>
> Probably you should be subscribed to d-d-a and reading the list.
Both questions were posted before that d-d-a ones.
--
Eugene V. Lyubimki
rom completely different, non-Debian repositories:
Package: some-package
Depends: gnome
Recommended-When: gnome
And, still wearing the hat, negations are fairly easy to implement. If
we ever go for implementing conditional dependencies, negations are
great and powerful idea, I'd vote for them.
On 2011-05-20 13:58, Julian Andres Klode wrote:
> Eugene thinks it is unfair if APT were to pre-depend on things while
> Cupt would not [...]
No, I didn't say that. I did say it is possible to upgrade a Debian
system without APT, and you cannot attribute anything beyond this to
me.
-
, depending only
> on some quite low-level libraries, so the impact should be minimal.
Yes, that's true.
For me, it's very-minimal-value positive versus minimal-value negative.
--
Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com
C++/Perl developer, Debian Devel
won't be
> able to restart apt to let it finish it.
As you and me pointed already, there are other (hard or easy) ways and
tools to fix the system. APT is not Essential, a system can live without
it.
--
Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com
C++/Perl developer, D
a
> > strong objection.
> No. We *should* require consensus. The only way to force a change
> against the maintainer's will is tech-ctte or a GR. We do not have a
> clear decision in the APT team yet, though, as mvo is not here
> currently.
I wonder what's the point o
count the situation for resuming broken upgrade, there is a
some chance you'll have to call dpkg manually or some hacks
to proceed anyway.
--
Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com
C++/Perl developer, Debian Developer
--
To UNSUBSCRIBE, email to de
;> greater than lenny and squeeze we should switch to Debian version
> >> numbers in the version instead of codenames post-squeeze.
> >> (OTOH it needs to be greater than +squeeze then, so +debXY won't do.)
> > Maybe +rXY as in r for release?
>
> r < s, though
l (lib*, python-*,
> and so on). So, I still prefer a file-trigger.
Sure, using APT hooks is a hack (like Goswin said already). From the
time output above, I see it's now much faster than the man-db trigger? If
so, I would say go ahead with file triggers.
--
Eugene V. Lyubimkin aka JackYF, JI
of operations)
No, I phrased it badly probably. Let me try again:
Dpkg::Pre-Invoke are called once. Then all dpkg invocations are called.
The Dpkg::Post-Invoke is called.
--
Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com
C++/Perl developer, Debian Developer
--
To
gt; But those hooks would only wotk for apt/aptitude. Not for [...] cupt
This is not true as well.
--
Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com
C++/Perl developer, Debian Developer
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of &qu
prefer dropping only one hashsum (of 3) though.
> Would that already help quite a bit? The description and the hashsums
> probably contain a tad more entropy than the other bits and could
> already help quite a bit.
++
--
Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.co
tlessly
> abrasive, inappropriate and offensive?
I also don't like the style of the answer. Nevertheless, while I see
your rationale, I doubt it's enough to overrule the maintainer.
--
Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com
C++/Perl developer, Debian Develo
tagged, removed, have version information set
> differently, or something in order to remove it from the UDD query for
> "squeeze bugs"?
IMHO this bug should be tagged 'sid' then.
--
Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com
C++/Perl developer,
is
> hidden on unpack (I certainly wouldn't if I were them), so implementing
> this is kind of pointless for Debian.
>
Seconded.
--
Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com
C++/Perl developer, Debian Developer
signature.asc
Description: OpenPGP digital signature
at a
> sponsor be automatically subscribed to the bugs for all packages he
> sponsors.
I think it's a good idea, but this probably belongs to another thread.
--
Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com
C++/Perl developer, Debian Developer
signature.asc
Description: OpenPGP digital signature
edata' for first and 'puredata-extended' for second sound better for
me (I also think that 'pd' is just too common)
--
Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com
C++/Perl developer, Debian Developer
signature.asc
Description: OpenPGP digital signature
#x27; and vice-versa.
Still can be resolvered by merging together (quite complex from packaging side
but possible).
--
Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com
C++/Perl developer, Debian Developer
signature.asc
Description: OpenPGP digital signature
--=20
Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com
C++/Perl developer, Debian Developer
signature.asc
Description: OpenPGP digital signature
cumented in README.Debian in the insserv package.
--
Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com
C++/Perl developer, Debian Developer
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.deb
>=20
> Opinions?=20
I would prefer 1. or, slightly less, 4.
--=20
Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com
C++/Perl developer, Debian Developer
signature.asc
Description: OpenPGP digital signature
David Paleino wrote:
> Eugene V. Lyubimkin wrote:
>> No, it doesn't. Dpkg and any sane high-level package manager won't
>> consider installing/upgrading/keeping some package (meta or not) without
>> all Depends installed.
>
> We can always change our tools
and it won't be pulled for
Recommends/Suggests).
To summarize: if I am not mistaken, this DEP cannot be implemented due to
technical reasons in its current form.
--
Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com
C++/Perl developer, Debian Developer
signature.asc
Description: OpenPGP digital signature
It gives examples of where things can be put in, were you
> inclined to do different things based on how the script is called.
It gives only a code template to do different things, but actually does nothing.
--
Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com
C++/Perl developer, Debian Developer
signature.asc
Description: OpenPGP digital signature
gt; future or in other places.
>[...]
>
> A failure of imagination on our art should not be used to block
> this functionality for cases where it might be needed.
With that kind of arguments, the standards cannot ever rid of unused bits.
I am giving up on this proposal
ure or in other places.
I always wondered how this params can be used by maintainer scripts, even in
theory.
--
Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com
C++/Perl developer, Debian Developer
signature.asc
Description: OpenPGP digital signature
prerm, postinst) - for sure;
- (postrm) - most probably, checked only a
part so far.
So, the question: how do people think, is a goal to deprecate&remove these
params in dpkg and policy worthy?
--
Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com
C++/Perl developer, Debian
original tarball works better IMO.
--
Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com
C++/Perl developer, Debian Developer
signature.asc
Description: OpenPGP digital signature
:-)
Would be nice to see also 1280x800.
--
Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com
C++/Perl developer, Debian Developer
signature.asc
Description: OpenPGP digital signature
kage. Many
> of those either Recommend the relevant package or declare no
> relationship at all.
>
'perl-modules', unlike usual binary/data split, contain executable code that
depends on executable code from 'perl', so it is not another foo-data package.
--
Eugen
is too generic. Can you change it to 'sandboxgamemaker'?
--
Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com
C++/Perl developer, Debian Developer
signature.asc
Description: OpenPGP digital signature
Anton Piatek wrote:
> 2009/9/19 Eugene V. Lyubimkin :
>> Anton Piatek wrote:
>>>> This should really be done by the package management, not by the user.
>>> It sounds like you are describing the following:
>>>>> $stable: package foo
>>> manu
flicts
>>> foo}
> foo should now be marked as removeable, bar should be marked as
> manually installed (i.e. take the state associated with foo)
>
> Can any of that be achieved with postinst scripts?
That's a very bad idea IMO.
--
Eugene V. Lyubimkin aka JackYF, JID
Magnus Holmgren wrote:
> On fredagen den 18 september 2009, Eugene V. Lyubimkin wrote:
>> Magnus Holmgren wrote:
>>> I propose a new control field called e.g. Supersedes that will provide
>>> the same semantics. In its simplest form, a renamed package will declare
>
ew one, i.e. explicitly
declared upgrade path.
--
Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com
C++/Perl developer, Debian Developer
signature.asc
Description: OpenPGP digital signature
Andreas Tille wrote:
> On Wed, Aug 19, 2009 at 11:35:10AM +0300, Eugene V. Lyubimkin wrote:
>>>apt-get --include-suggest install
>>>
>> -o 'Apt::Install-Suggests=1'
>
> Ahh, I remember I was formerly wondering about this option which might
> be
Andreas Tille wrote:
> I even failed to grep "man apt-get" for the string "suggests" so
> I think I can not do something like
>
>apt-get --include-suggest install
>
-o 'Apt::Install-Suggests=1'
--
Eugene V. Lyubimkin aka JackYF, JID: jack
Philipp Kern wrote:
> On 2009-08-13, Eugene V. Lyubimkin wrote:
>>> Maybe you should spend some time and read the thread before stating such
>>> things.
>> Really? So, they are already first-class deb packages?
>
> Maybe you should spend some time and re
Emilio Pozuelo Monfort wrote:
> Eugene V. Lyubimkin wrote:
>> Hello thread! /me puts on a package manager developer hat.
>>
>> Sorry, I haven't read the whole thread, it's huge.
>>
>> I think that diversion of debug packages out of current deb format is a
n't be first-class Debian packages
Fully agree.
While I support automatic generation of debug packages, creating a new format
for them sounds for me as creating new RFC for e-mails which bodies contain no
spaces and no Bcc header allowed. Why? To filter 'automatic debug mails'.
--
r maintainers of reverse depends,
opposing to your. It has discussed drawback too, of course.
That's all my arguments.
--
Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com
C++/Perl developer, Debian Maintainer
signature.asc
Description: OpenPGP digital signature
Aurelien Jarno wrote:
> Except saying "apt sucks", I currently do not have more idea. Someone
> else maybe?
>
/me suggests to try cupt and hides
--
Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com
C++/Perl developer, Debian Maintainer
signature.asc
D
Goswin von Brederlow wrote:
> "Eugene V. Lyubimkin" writes:
>
>> Goswin von Brederlow wrote:
>>> "Eugene V. Lyubimkin" writes:
>>>>> 2) Tagging package relationships instead of packages means extending
>>>>> the syntax o
Goswin von Brederlow wrote:
> "Eugene V. Lyubimkin" writes:
>>> 2) Tagging package relationships instead of packages means extending
>>> the syntax of package relationsships, trusting the binary packages to
>>> get the depends right
>> You'll
Goswin von Brederlow wrote:
> "Eugene V. Lyubimkin" writes:
>> What the multiarch spec proposes now is package-oriented approach: the
>> package
>> should define whether it is 'same' or 'foreign' kind. This is not
>> straightforwar
Hi Steve,
Steve Langasek wrote:
> Hi Eugene,
>
> On Wed, Jul 29, 2009 at 09:34:42PM +0300, Eugene V. Lyubimkin wrote:
>
>> Moreover, this is not the only exception. Thousands of desktop and server
>> packages that contains executable binaries (applications) compiled
dependencies as
multiarch 'same' to allow foreign dependencies to be satisfied with less
number of packages in the system in the long run.
--
Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com
C++/Perl developer, Debian Maintainer
signature.asc
Description: OpenPGP digital signature
Bill Allombert wrote:
> I use packages.debian.org each time I reassign a bug to a package to make
> sure the new maintainer is notified. I think this should be a best
> practice.
BTS automatically adds maintainers of package where bug went to To/CC of
reassign mail, doesn't it?
While this is true, the approach has two drawbacks:
1) depending on newer apt version would lead to uninstallability on
Lenny, while now cupt can be installed on pure-Lenny system
2) waiting for fix in apt can take significant time
Given all this, are there arguments against that chmod command?
--
Euge
Package: wnpp
Severity: wishlist
Owner: "Eugene V. Lyubimkin"
* Package name: cupt
Version : 0.1.0
Upstream Author : Eugene V. Lyubimkin
* URL : http://wiki.github.com/jackyf/cupt
* License : GPL3+ | Artistic
Programming Lang: Perl
D
Darren Salt wrote:
> I demand that Eugene V. Lyubimkin may or may not have written...
>
>> kc.ubuntu...@centrum.cz wrote:
>> <...>
> [note: reformatted]
>> I don't feel comfortable to answer on your mails. Use '>' for quoting,
>> don'
to configure your mail client?
Or wait for a person who is conformable with this kind of mails.
--
Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com
C++/Perl developer, Debian Maintainer
signature.asc
Description: OpenPGP digital signature
grading packages may break your system (by design, in any software). So,
all downgrades should be done with caution and in not-automatic way.
> OK. Maybe i just supposed APT to do various things I'm used to expect from
> other package managements. Now i undrstand, reading the point of
rom
> Opensuse?
APT team has a number of tasks to work. As usually, patches are usually welcome.
I obviously think that "incapable and obsolete" (from subject of the letter)
aren't the words which can characterize APT.
With 'APT contributor' hat on,
--
Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com
C++/Perl developer, Debian Maintainer
signature.asc
Description: OpenPGP digital signature
3:31:30 UTC on February 13, 2009, a celebration is expected as the
> Unix time number reaches 1234567890 seconds. [1]
Well, but Feb 14 is the Valentine's Day, fun seems to be already planned ;)
--
Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com
C++/Perl developer, Debian Maint
Diffs are like to be produced by dak, so
please try first
asking the ftp masters.
--
Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com
Ukrainian C++ developer, Debian Maintainer, APT contributor
signature.asc
Description: OpenPGP digital signature
Neil Williams wrote:
> A final alternative is the packages.debian.org website (has the
> advantage that it also allows looking up files within packages that are
> not currently installed).
We also have apt-file utility, which does the same without looking to the site.
--
Eugene V. Lyub
say which package man page belongs to.
Example for coreutils:
$ dpkg -S mv.1
coreutils: /usr/share/man/man1/mv.1.gz
git-core: /usr/share/man/man1/git-mv.1.gz
Look, first package is what you want.
Is this approach acceptable for your needs?
--
Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(mail
Frans Pop wrote:
> The Debian CD team has made practical use of the extra time allowed for
> the release of Lenny by implementing some late improvements of the CD and
> DVD images available for Lenny
[snip]
Thanks for massive work!
--
Eugene V. Lyubimkin aka JackYF, JID: jackyf.deve
nacceptable to drop fbreader from Lenny. Please
coordinate with
me. (BTW, I was not anyhow pinged and noticed this only right now and only by
good chance.
Badly.)
--
Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com
Ukrainian C++ developer, Debian Maintainer, APT
Tracking System that permits RC bugs to remain in the next releases of
> Debian when the report is closed incorrectly and nobody notices before
> they are out.
bug-maint-info.txt file is in package 'doc-debian', reassigned
--
Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)
Artyom Shalkhakov wrote:
> 2008/12/24 Eugene V. Lyubimkin :
>> Which means that "find all dependencies with no exceptions" is not true.
>
> This is how Nix developers put it:
>
>> Runtime dependencies are found by scanning binaries for the hash parts
>&
isn't backed by facts,
One big fact is: Debian have tens (or even hundreds) of tools that use apt
infrastructure, including both user side and archive maintenance side. Nix, in
any way it operates, suggests other API to maintain packages. Who is supposed
to rewrite all this stuff for Nix?
>
we have not-so-excellent, but rather good apt, and
significant amount of Debian users choose Debian just only because of apt. IMO.
--
Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com
Ukrainian C++ Developer, Debian Maintainer, APT contributor
signature.asc
Description: OpenPGP digital signature
t that is another discussion :-)
Actually, apt-get is more often used as non-interactive package manager, so I
would not
add interactive "asker" to it. Aptitude, however, has all chances and
opportunities to
implement it.
All above is IMO.
--
Eugene V. Lyubimkin aka JackYF, JID: jac
1 - 100 of 135 matches
Mail list logo
